Re: Why isn't Java support part of Postgresql core?

From: cowwoc <cowwoc(at)bbs(dot)darktech(dot)org>
To: Szymon Guz <mabewlun(at)gmail(dot)com>
Cc: PostgreSQL <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why isn't Java support part of Postgresql core?
Date: 2014-09-19 08:19:03
Message-ID: 541BE6F7.501@bbs.darktech.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I am beginning to feel like people are putting words in my mouth :)

I agree with most of what you said. I will only comment on the differences:

> There is nothing special in java, that's just another language like
> perl, python and tcl. I don't see any reason to treat that differently.

I don't disagree per-se. I think bundling the JRE would help users, but
it's a tiny problem compared to needing to build pl/java from source. If
we can fix the latter, the former is a smaller issue. Sidenote: when I
talk about "bundling" the JRE I simply mean adding an option in the
installer to download and unpack it on behalf of the user.

> If there is a programmer who cannot install jvm/jdk on its own (which
> is a couple of clicks on windows and linux) then I'm sure that writing
> stored procerures in java will be even too difficult.

Installing a public JVM is easy. Binding it to pl/java is not. By
bundling a private JRE we control the default installation path and can
therefore pre-configure pl/java to look for it in that location.

On 19/09/2014 3:18 AM, Szymon Guz wrote:
> You only forgot about the guava version. What if I need another version?

I never meant to imply we would bundle Java libraries with pl/java. The
only thing we should bundle is the private JRE. Users will be
responsible for adding libraries to the classpath in the same way they
add their triggers.

> And yes, there are different java versions which are not compatible.
> If I have 32bit java and 64bit java, I can get OOM on the 32 bit jvm,
> which I will not get on the 64bit one. Which means they are not
> compatible. Also many libraries are not compatible. What should I do
> then if the database has only one version I can use?

32-bit and 64-bit are two different platforms. Users can still replace
the bundled JRE (it should work fine) but we only need to test against
one implementation per platform.

> I also don't like the idea that you want to stick to just one
> implementation. Let's assume that postgres will have java 1.7 for the
> next 10 years. Just because someone made the decision. Any java 1.8
> code which uses the new java features will not run on this machine,
> and the user will not be able to use its own jvm with his own
> procedures written in this new java version. And then one day there
> will be an incompatible java release most people are talking about,
> what then?

1. The oldest dependency I see in the "lib" directory is from 2012.
What makes you believe they would refuse to update a dependency for
10 years? A private JRE is just a library. It's no different from
anything else.
2. The user can still replace the JRE themselves if they need to. This
is less user friendly, but it's doable.

> I really like the idea that users can just link postgres with anything
> they want. Postgres will have just interface, and the things it will
> link to will be provided by the users.

I'm not taking this option away from you. Power users can still do what
they want. I'm just trying to facilitate deployment users who are fine
with the default/typical configuration.

Gili

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Szymon Guz 2014-09-19 08:30:13 Re: Why isn't Java support part of Postgresql core?
Previous Message Alban Hertroys 2014-09-19 08:18:53 Re: How can i monitor exactly what (partition) tables are accessed by a query?