Re: Why isn't Java support part of Postgresql core? - Mailing list pgsql-general
| From | cowwoc |
|---|---|
| Subject | Re: Why isn't Java support part of Postgresql core? |
| Date | |
| Msg-id | 541BE6F7.501@bbs.darktech.org Whole thread Raw |
| In response to | Re: Why isn't Java support part of Postgresql core? (Szymon Guz <mabewlun@gmail.com>) |
| Responses |
Re: Why isn't Java support part of Postgresql core?
Re: Why isn't Java support part of Postgresql core? |
| List | 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:
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.
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:
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?
- 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.
- 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
pgsql-general by date: