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.
