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:
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.
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'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 |