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: Re: Why isn't Java support part of Postgresql core?
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
