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

On 18/09/2014 4:26 PM, David G Johnston [via PostgreSQL] wrote:
> ​ "only PostgreSQL uses it" ... PostgreSQL doesn't use Java.

I don't think it makes a difference from a licensing point of view. The
point is that the JRE is not used to run multiple distinct applications.

> You want PostgreSQL to pick a single implementation of Java and make
> it accessible via the pl/java language so that people can write
> triggers in Java instead of pl/pgsql. What I don't understand is
> whether you expect those triggers to call out to other Java code that
> the trigger writers may have written? That they would is being
> assumed and those external Java programs are what will have been
> tested, by the user, on specific combinations of JRE and OS that
> PostgreSQL may not be providing.

Let's talk about a concrete example. You're worried that PG will invoke
MyTrigger.java which uses Google Guava under the hood, and Guava (in
turn) will not run properly on the specific vendor/version we support?
This is Java we're talking about. There are very few incompatibilities
between JVM vendors and version and the ones that exist are very
manageable. I don't see a problem with picking a single implementation
and telling users their code must be compatible with it. In the past 12
years of working with Java I have not once run across an incompatibility
that was caused by the JVM. Every single time, it was a problem with
user code making assumptions which were not guaranteed by the
specification (i.e. their own problem).

> ​Also, there is no functional difference between a public and a
> private JRE.​ Pointing pl/java to a private JRE is no more or less
> secure than pointing it to whatever public JRE the administrator
> happens to have installed.

A public JRE is exploitable through web browsers, which have a much
larger attack surface than PostgreSQL does. To exploit the private JRE,
you'd need to write a JAR file to disk and have permissions to create a
new trigger. Alternatively, you'd need to have permission to invoke
existing triggers and know which combination of inputs could be used to
exploit a JRE bug. The latter is equivalent to a bug you would find in
any native libraries, like the recent heartbleed bug. It happens, but
that's no more vulnerable than any other native library.

> The choice of valid integrations between different applications is a
> decision best left to packagers (I deem install-from-source people
> their own packager in this context). I think it would be great to
> issue "apt-get install postgresql9.4-pljava-oraclejava8" and BOOM! I
> issue my CREATE EXTENSION and I'm ready to go.

I'm fine with that. I'm just saying that we should provide/support at
least one option. If they want to install a different JVM that's up to
them (and I see no problem with that).

> If we get to this point then why not have pljava-oracle-v8;
> pljava-oracle-v6; pljava-openjdk-v7 as separate languages with private
> JREs that can be installed side-by-side and the user can pick the one
> they wish to use?

If you want to support these many combinations, all the power to you. I
am only advocating officially supporting one combination and letting
people use other packages if they so wish. Again, I don't foresee any
major incompatibilities by using oracle vs openjdk. GCJ is a different
story and I would discourage its use.

> There is a lot that can be done in this area but someone - and not the
> core developers - needs to champion the cause; providing or asking for
> specific core enhancements to be made as integration problems arise.
> Then help the various packagers create the packages needed for
> end-users to easily install the final result on their system

Right. I've shifted the discussion to targeting packagers, not the core
developers. I just want to make sure the core developers are comfortable
with this arrangement from a licensing/distribution/support point of view.

Gili

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819560.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.