Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 18 September 2014 22:58, cowwoc cow...@bbs.darktech.org wrote: Hi, I'm observing the whole discussion, and I really don't like the idea of adding everything to the core. I fully agree that the core should be small, as small as possible. The way it works now is that it provides interfaces to the external languages like perl or python. This way we could add pljava to the core, but as the normal procedural language. Just next to plperl and plpython. There are just interfacese to external interpreters of perl, python and tcl. There could be another to the external java. But external, not in core. 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 think we could add the pljava to the core, but not with jre. If there should be jre why will java be treated specially? Why not add python, perl, and tcl there? In all possible versions? Why just use one version, which will not be used by all programmers? Adding external binaries to the core provides many questions like: - which version of the language interpreter/vm? All of them? - why one language should be treated specially? - what if I want to use two separate versions for two databases in the same cluster? 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. I think that the good things for java and postgres would be: - improve pljava so it works without any problems (if there are any things to be fixed, I don't know that, but someone wrote in this thread that there are some problems) - add pljava to the pgxn - promote it by some nice examples - when pljava would be in the core, then we could add additional info to the official postgres documentation - improve jdbc driver, which is currently a huge bunch of terribly unreadible code which doesn't follow any of the modern java conventions and has a couple of jdbc things not implemented (I know, there are too little programmers for this project, there are historical issues, and the driver just works - works but it's hard to modify) - create a library to do some more complicated administration things from java, which would be nice, as I observed too many java programmers who are really afraid of touching any database administration And of course the one small remark about Postgres. It's an open source project, everybody can fix it, add things he or she thinks are needed. The things then can be added to the core, or not. For instance Pavel wrote a patch for unicode border lines in psql which was on his page for some long time before merging that to the core, and I was using the patch on my own, and it was quite nice. I think the first steps for java in postgres should be testing and fixing pljava outside the core. Then there should be nice and readible procedure for installing that. We could add information about this external procedural language to the official postgres documentation without any problem. If someone is smart enough to write a procedure in java, I'm sure there won't be problems with installing jre/jdk and adding the extension. 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). You only forgot about the guava version. What if I need another version? 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? I also don't like the idea that you want to stick to just one implementation. Let's assume that postgres will
Re: [GENERAL] Why isn't Java support part of Postgresql core?
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: 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? 1. 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. 2. 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
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 19 September 2014 10:19, cowwoc cow...@bbs.darktech.org wrote: 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. Adding an option to the installer is something else than adding the jre into the core. Installer for windows can install many different things which are not in the core. The linux installer is another thing, I'm not using an installer, I've got debs in repository, having one more package for the pljava is not a bad idea. However another package is not the same as jre in the core postgres. As far as I remember the windows installer can also install postgis, which definitely is not a part of postgres, but it's an external library. I think all people here agree that adding another package to linux repository or an option to windows installer is OK. What some people disagree here is adding jre to the core postgres. Oh, and btw, I've got a package named postgresql-9.3-pljava-gcj in my linux repo. 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. The best solution would be to make different languages, like pljava6, pljava7, pljava8, with library path configured in the create extension command. This way we could use different jvms and library versions for each database. But this still doesn't mean adding jre to the core postgres. 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. So in fact you propose to create another option in the windows installer only, right? Szymon
Re: [GENERAL] Why isn't Java support part of Postgresql core?
These are minor nitpicks but they address significant questions about the scope of core. On Fri, Sep 19, 2014 at 1:19 AM, cowwoc cow...@bbs.darktech.org wrote: 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. Does core even maintain installers? If so, which ones? I don't disagree with the goal of making the software easy to install, but asking the core team to maintain it so it will end up in Stack Builder is the wrong approach. 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. One more question is who is we? And are the same considerations on Debian and RHEL as on Windows? And if not, then is the best approach here to work first with packagers here? What about source compilations? To be honest I suspect that the following would be a more productive approach: 1. The pl/java project needs to ensure the software is easy to install. Nobody else is going to be able to take that over. 2. Evangelism on the capabilities of the project including in migrations from Oracle etc. needs to be given a priority. Community building is good. 3. Work with packagers to get the software easily installable on multiple platforms. Work with the maintainers of the Windows installer to include that. Work with packagers on Debian, RHEL, Fedora, etc. for that. I think that process will get you everything and more that handing it off to core would. -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 19/09/2014 4:30 AM, Szymon Guz wrote: I think all people here agree that adding another package to linux repository or an option to windows installer is OK. What some people disagree here is adding jre to the core postgres. So we're in agreement. Oh, and btw, I've got a package named postgresql-9.3-pljava-gcj in my linux repo. Good to know, but for now I'm developing primarily on Windows machines. 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. The best solution would be to make different languages, like pljava6, pljava7, pljava8, with library path configured in the create extension command. This way we could use different jvms and library versions for each database. That's fine with me. 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. So in fact you propose to create another option in the windows installer only, right? Correct. Gili
Re: [GENERAL] Why isn't Java support part of Postgresql core?
2014-09-15 9:22 GMT+04:00 cowwoc cow...@bbs.darktech.org: Hi, Out of curiosity, why is Postgresql's Java support so poor? I am specifically looking for the ability to write triggers in Java. I took a look at the PL/Java project and it looked both incomplete and dead, yet other languages like Javascript are taking off. I would have expected to see very strong support for Java because it's the most frequently used language on the server-side. What's going on? Why isn't this a core language supported alongside SQL, Perl and Python as part of the core project? Out of curiosity and what's going on? Why there is no Common Lisp in PostgresSQL's core? :-) -- // Dmitriy.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 09/19/2014 02:10 PM, Dmitriy Igrishin wrote: 2014-09-15 9:22 GMT+04:00 cowwoc cow...@bbs.darktech.org mailto:cow...@bbs.darktech.org: Hi, Out of curiosity, why is Postgresql's Java support so poor? I am specifically looking for the ability to write triggers in Java. I took a look at the PL/Java project and it looked both incomplete and dead, yet other languages like Javascript are taking off. I would have expected to see very strong support for Java because it's the most frequently used language on the server-side. What's going on? Why isn't this a core language supported alongside SQL, Perl and Python as part of the core project? Out of curiosity and what's going on? Why there is no Common Lisp in PostgresSQL's core? :-) -- // Dmitriy. Dmitri, please be careful. Your risking all the emacs users chiming in!
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Fri, Sep 19, 2014 at 1:10 PM, Dmitriy Igrishin dmit...@gmail.com wrote: 2014-09-15 9:22 GMT+04:00 cowwoc cow...@bbs.darktech.org: Hi, Out of curiosity, why is Postgresql's Java support so poor? I am specifically looking for the ability to write triggers in Java. I took a look at the PL/Java project and it looked both incomplete and dead, yet other languages like Javascript are taking off. I would have expected to see very strong support for Java because it's the most frequently used language on the server-side. What's going on? Why isn't this a core language supported alongside SQL, Perl and Python as part of the core project? Out of curiosity and what's going on? Why there is no Common Lisp in PostgresSQL's core? :-) Armed Bear Common Lisp should be accessible from pl/java right? *ducks* -- // Dmitriy. -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
Re: [GENERAL] Why isn't Java support part of Postgresql core?
Chris, On 18/09/2014 1:07 AM, Chris Travers wrote: On Wed, Sep 17, 2014 at 9:42 PM, cowwoc cow...@bbs.darktech.org mailto:cow...@bbs.darktech.org wrote: Tom, For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do. The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path). But what the core team has done is provide a pretty stable interface for getting to that point. The extension interface is well documented and quite stable IME. If the pl/java project can't get it to a point where you can make make install, then I don't see what would possibly benefit from getting into core. Bare with me for a moment while I walk you through the Windows (for dummies) experience I had in mind. If you take a look at the Windows installation, it ships with lib/hstore.dll which enables users to invoke make extension hstore (no need to build anything). I'm talking about doing the same thing for pljava. I suggest adding an optional feature in the Windows installer (I believe it's called Application Stack Builder) for pljava. When enabled, it would unpack lib/pljava.dll and a private JRE (so users don't have to mess around with library paths). Users can then enable the extension with a simple invocation of CREATE EXTENSION pljava. It doesn't get easier than this. And of course you'd do the equivalent thing for *nix (investigate how it works for hstore and provide an equivalent experience for pljava). Gili
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Thursday, September 18, 2014, cowwoc cow...@bbs.darktech.org wrote: Chris, On 18/09/2014 1:07 AM, Chris Travers wrote: On Wed, Sep 17, 2014 at 9:42 PM, cowwoc cow...@bbs.darktech.org javascript:_e(%7B%7D,'cvml','cow...@bbs.darktech.org'); wrote: Tom, For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do. The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path). But what the core team has done is provide a pretty stable interface for getting to that point. The extension interface is well documented and quite stable IME. If the pl/java project can't get it to a point where you can make make install, then I don't see what would possibly benefit from getting into core. Bare with me for a moment while I walk you through the Windows (for dummies) experience I had in mind. If you take a look at the Windows installation, it ships with lib/hstore.dll which enables users to invoke make extension hstore (no need to build anything). I'm talking about doing the same thing for pljava. I suggest adding an optional feature in the Windows installer (I believe it's called Application Stack Builder) for pljava. When enabled, it would unpack lib/pljava.dll and a private JRE (so users don't have to mess around with library paths). Users can then enable the extension with a simple invocation of CREATE EXTENSION pljava. It doesn't get easier than this. And of course you'd do the equivalent thing for *nix (investigate how it works for hstore and provide an equivalent experience for pljava). Gili Hi Gili, Yes, but pre-condition for that, is to an extension is in the state where all what is needed to be done is make make install, after that CREATE EXTENSION in db. Hstore, ltree, uuid-ossp etc are all pg extensions already in that state for what is made decision that can be shipped together with postgres installation - so building is done during installation of postgres (optionally) - because of that end user just need to do CREATE EXTENSION pl/java is far away from that state - once it get to that state. Pg core team could take it in consideration if extension is stable enough to can be shipped together with core... In my opinion - for pljava would be great just to get to that state - to install it easy... Less important if it is shipped together with core.. But I guess it is more for pl/java authors... Or whoever knows how to do it and is keen to do it - open source... Kind Regards, Misa
Re: [GENERAL] Why isn't Java support part of Postgresql core?
cowwoc wrote Chris, On 18/09/2014 1:07 AM, Chris Travers wrote: On Wed, Sep 17, 2014 at 9:42 PM, cowwoc lt; cowwoc@.darktech gt; lt;mailto: cowwoc@.darktech gt; wrote: Tom, For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do. The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path). But what the core team has done is provide a pretty stable interface for getting to that point. The extension interface is well documented and quite stable IME. If the pl/java project can't get it to a point where you can make make install, then I don't see what would possibly benefit from getting into core. Bare with me for a moment while I walk you through the Windows (for dummies) experience I had in mind. If you take a look at the Windows installation, it ships with lib/hstore.dll which enables users to invoke make extension hstore (no need to build anything). I'm talking about doing the same thing for pljava. I suggest adding an optional feature in the Windows installer (I believe it's called Application Stack Builder) for pljava. When enabled, it would unpack lib/pljava.dll and a private JRE (so users don't have to mess around with library paths). Users can then enable the extension with a simple invocation of CREATE EXTENSION pljava. What distributions of JRE are available on the Windows platform and which ones are allowed to be privately distributed? For this scenario your target audience is the people, at EnterpriseDB, who package the Windows installer. IIRC PostGIS is part of the builder - and it is definitely not core maintained - so pl/java should be no different. Each platform is different and the package builders should deal with making pl/java easy deploy - but the project itself needs to help facilitate that end (through code and documentation). Regardless, the core team, for reasons already stated, likely will not and should not be the maintainers of pl/java. It needs to be an extension and interface with PostgreSQL via the provided mechanisms. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819489.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/18/2014 6:18 AM, David G Johnston wrote: What distributions of JRE are available on the Windows platform and which ones are allowed to be privately distributed? afaik, Sun/Oracle is /the/ Java for Windows, and AFAIK, it does NOT allow redistribution, Oracle wants you to register each usage. also as far as I know, java on 64bit windows defaults to only installing a 32 bit java, since thats what most browsers use. hmmm, for extra fun, the JRE 7 I have on my win8 box here, I'm not even SEEING the server/jni libraries?!? -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 18 September 2014 17:32, John R Pierce pie...@hogranch.com wrote: On 9/18/2014 6:18 AM, David G Johnston wrote: What distributions of JRE are available on the Windows platform and which ones are allowed to be privately distributed? afaik, Sun/Oracle is /the/ Java for Windows, and AFAIK, it does NOT allow redistribution, Oracle wants you to register each usage. also as far as I know, java on 64bit windows defaults to only installing a 32 bit java, since thats what most browsers use. hmmm, for extra fun, the JRE 7 I have on my win8 box here, I'm not even SEEING the server/jni libraries?!? Are we distributing perl and python with postgres as well?
Re: [GENERAL] Why isn't Java support part of Postgresql core?
John, You are confusing a private JRE installation with the public JRE installation (yes, there is such a thing). The public JRE is found in java/jre8. The private JRE is found in java/jdk1.8.0_20/jre. http://www.oracle.com/technetwork/java/javase/jdk-8-readme-2095712.html#redistribution gives you permission to redistribute the JRE directory that ships inside each JDK installation. If you dig into jre/bin/server you will find jvm.dll. As far as I know, creating and redistributing a private JRE should be very easy to do. Plenty of organizations do it and it works well. Gili On 18/09/2014 11:33 AM, John R Pierce [via PostgreSQL] wrote: On 9/18/2014 6:18 AM, David G Johnston wrote: What distributions of JRE are available on the Windows platform and which ones are allowed to be privately distributed? afaik, Sun/Oracle is /the/ Java for Windows, and AFAIK, it does NOT allow redistribution, Oracle wants you to register each usage. also as far as I know, java on 64bit windows defaults to only installing a 32 bit java, since thats what most browsers use. hmmm, for extra fun, the JRE 7 I have on my win8 box here, I'm not even SEEING the server/jni libraries?!? -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list ([hidden email] /user/SendEmail.jtp?type=nodenode=5819509i=0) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general If you reply to this email, your message will be added to the discussion below: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819509.html To unsubscribe from Why isn't Java support part of Postgresql core?, click here http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5819025code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3. NAML http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819513.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 18/09/2014 9:18 AM, David G Johnston [via PostgreSQL] wrote: What distributions of JRE are available on the Windows platform and which ones are allowed to be privately distributed? (Answered in a follow-up email to John Pierce) For this scenario your target audience is the people, at EnterpriseDB, who package the Windows installer. IIRC PostGIS is part of the builder - and it is definitely not core maintained - so pl/java should be no different. Each platform is different and the package builders should deal with making pl/java easy deploy - but the project itself needs to help facilitate that end (through code and documentation). Regardless, the core team, for reasons already stated, likely will not and should not be the maintainers of pl/java. It needs to be an extension and interface with PostgreSQL via the provided mechanisms. Agreed. Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819512.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/18/2014 9:07 AM, cowwoc wrote:
You are confusing a private JRE installation with the public JRE
installation (yes, there is such a thing). The public JRE is found in
java/jre8. The private JRE is found in java/jdk1.8.0_20/jre.
http://www.oracle.com/technetwork/java/javase/jdk-8-readme-2095712.html#redistribution
gives you permission to redistribute the JRE directory that ships
inside each JDK installation. If you dig into jre/bin/server you will
find jvm.dll.
ah, that I see... C:\Program Files\Java\jre7\bin\server\jvm.dll
for some reason I was thinking it needed {lib}jni.{so,dll}
--
john r pierce 37N 122W
somewhere on the middle of the left coast
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 18 September 2014 18:54, John R Pierce pie...@hogranch.com wrote:
On 9/18/2014 9:07 AM, cowwoc wrote:
You are confusing a private JRE installation with the public JRE
installation (yes, there is such a thing). The public JRE is found in
java/jre8. The private JRE is found in java/jdk1.8.0_20/jre.
http://www.oracle.com/technetwork/java/javase/jdk-8-readme-2095712.html#
redistribution gives you permission to redistribute the JRE directory
that ships inside each JDK installation. If you dig into jre/bin/server you
will find jvm.dll.
ah, that I see... C:\Program Files\Java\jre7\bin\server\jvm.dll
for some reason I was thinking it needed {lib}jni.{so,dll}
Does it mean that there should be distributed many jvm.dlls for each of the
jvm versions?
Szymon
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/18/2014 10:17 AM, Szymon Guz wrote: Does it mean that there should be distributed many jvm.dlls for each of the jvm versions? jvm.dll is part of the jre, its not a standalone library. -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 18/09/2014 1:31 PM, John R Pierce [via PostgreSQL] wrote: On 9/18/2014 10:17 AM, Szymon Guz wrote: Does it mean that there should be distributed many jvm.dlls for each of the jvm versions? jvm.dll is part of the jre, its not a standalone library. Right, so to recap: each platform will only need one jvm.dll/so library (which you would update over time). You don't need to include one version for Oracle JDK, OpenJDK, GCJ. You'd pick one, and bundle its jvm.dll (I'd suggest going with Oracle's version since it has the best stability/performance story). I don't believe there are any licensing terms/requirements for private JREs beyond limiting which files you redistribute, so from a licensing point of view I think the Postgresql team would find it acceptable. Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819529.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/18/2014 11:06 AM, cowwoc wrote: On 18/09/2014 1:31 PM, John R Pierce [via PostgreSQL] wrote: On 9/18/2014 10:17 AM, Szymon Guz wrote: Does it mean that there should be distributed many jvm.dlls for each of the jvm versions? jvm.dll is part of the jre, its not a standalone library. Right, so to recap: each platform will only need one jvm.dll/so library (which you would update over time). You don't need to include one version for Oracle JDK, OpenJDK, GCJ. You'd pick one, and bundle its jvm.dll (I'd suggest going with Oracle's version since it has the best stability/performance story). I don't believe there are any licensing terms/requirements for private JREs beyond limiting which files you redistribute, so from a licensing point of view I think the Postgresql team would find it acceptable. um, I'm pretty sure that dll/so doesn't work without the rest of the JRE around it. I would think the platform packager would need to bundle the whole 'private' JRE they chose including that jvm.dll/so, and install that somewhere in or around the postgres code tree, along with the pljava.so/dll that binds it all together, if the user chooses to install pljava support. -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 18/09/2014 2:21 PM, John R Pierce [via PostgreSQL] wrote: Right, so to recap: each platform will only need one jvm.dll/so library (which you would update over time). You don't need to include one version for Oracle JDK, OpenJDK, GCJ. You'd pick one, and bundle its jvm.dll (I'd suggest going with Oracle's version since it has the best stability/performance story). I don't believe there are any licensing terms/requirements for private JREs beyond limiting which files you redistribute, so from a licensing point of view I think the Postgresql team would find it acceptable. um, I'm pretty sure that dll/so doesn't work without the rest of the JRE around it. I would think the platform packager would need to bundle the whole 'private' JRE they chose including that jvm.dll/so, and install that somewhere in or around the postgres code tree, along with the pljava.so/dll that binds it all together, if the user chooses to install pljava support. Yes, that's what I meant. I just wanted to reinforce the fact that you don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick one and bundle it alongside PG and pl/java. Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819533.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/18/2014 11:44 AM, cowwoc wrote: Yes, that's what I meant. I just wanted to reinforce the fact that you don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick one and bundle it alongside PG and pl/java. I think a lawyer would have to pick apart the JRE redistribution license to confirm that this use case is acceptable... the catch-22 is that pljava is running user java modules, not just the software its being distributed with, and I'm not sure the redistribution license allows that. specifically... License to Distribute Software. Subject to ..., Oracle grants you ... license ... to ... distribute the Software ..., provided that (i) you distribute the Software ... only bundled as part of, and for the sole purpose of running, your Programs, (ii)... its that 'sole purpose' part that I wonder about. FWIW, thats from the JRE 6 binary license, I didn't find the 7 or 8 one in a quick google search. -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 18/09/2014 3:17 PM, John R Pierce [via PostgreSQL] wrote: On 9/18/2014 11:44 AM, cowwoc wrote: Yes, that's what I meant. I just wanted to reinforce the fact that you don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick one and bundle it alongside PG and pl/java. I think a lawyer would have to pick apart the JRE redistribution license to confirm that this use case is acceptable... the catch-22 is that pljava is running user java modules, not just the software its being distributed with, and I'm not sure the redistribution license allows that. specifically... License to Distribute Software. Subject to ..., Oracle grants you ... license ... to ... distribute the Software ..., provided that (i) you distribute the Software ... only bundled as part of, and for the sole purpose of running, your Programs, (ii)... its that 'sole purpose' part that I wonder about. FWIW, thats from the JRE 6 binary license, I didn't find the 7 or 8 one in a quick google search. Plenty of other software is already doing this (e.g. Atlassian JIRA which is very well known and has hundreds of plugins). Oracle's main intent is to prevent redistributing of a public JRE without their consent, where public means a JRE used to run system-wide applications. According to http://www.oracle.com/technetwork/java/javase/jre-8-readme-2095710.html: When redistributing the JRE on Microsoft Windows as a private application runtime (*not accessible by other applications*) (Emphasis is mine) Whether it's user code running on it or not, it's still running as part of Postgresql so it's a private JRE. Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819539.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/18/2014 2:44 PM, cowwoc wrote: Yes, that's what I meant. I just wanted to reinforce the fact that you don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick one and bundle it alongside PG and pl/java. I've been following along as an interested observer, having used PL/Java in the past, and developing with Java for a living. I don't think bundling is a good idea. Gili, as you fully understand, Java is a moving target. Important vulnerabilities are discovered and updates are pushed out to address. So, any bundled version would be subject to possibly rapid obsolescence. Then there are organizational constraints or concerns. Some will only use official JDKs from Oracle/Sun, others will only use OpenJDK. Some won't move to a new major version until at least the .1 release, others stick with their Java 6 company-wide standard even though that version is officially EOL'd. So, in my opinion the least contentious way to go would be to have a set of instructions that inform the end user to install the JDK or JRE of their choice, subject to defined constraints. Then make PL/Java as painless as possible to install. This should not be a problem with larger organizations, since most use centrally-administered software configuration. Thanks. -- Guy Rouillier --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
Guy, As far as I understand, the concerns you brought up only apply to a public JRE. A private JRE is no different than any other library Postgresql links against. It's an implementation detail that does not affect your system-wide applications. Your vulnerability is no greater using an outdated private JRE than it is running an outdated version of Postgresql. All the Java vulnerabilities I am aware of have to do with running untrusted code on a public JRE (neither of which is being proposed). Lastly, nothing prevents you from upgrading the JRE directory yourself if you see fit (the JRE directory is a drop-in replacement with no external dependencies). It doesn't matter what brand of JRE you use, because only Postgresql uses it. Using the wrong brand will not cause your other applications to break (as it would if you were to replace a public JRE). Companies stick to Java 6 company-wide precisely because updating a public JRE would affect their other applications. Replacing a private JRE would not do that. Gili On 18/09/2014 3:40 PM, Guy Rouillier-4 [via PostgreSQL] wrote: On 9/18/2014 2:44 PM, cowwoc wrote: Yes, that's what I meant. I just wanted to reinforce the fact that you don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick one and bundle it alongside PG and pl/java. I've been following along as an interested observer, having used PL/Java in the past, and developing with Java for a living. I don't think bundling is a good idea. Gili, as you fully understand, Java is a moving target. Important vulnerabilities are discovered and updates are pushed out to address. So, any bundled version would be subject to possibly rapid obsolescence. Then there are organizational constraints or concerns. Some will only use official JDKs from Oracle/Sun, others will only use OpenJDK. Some won't move to a new major version until at least the .1 release, others stick with their Java 6 company-wide standard even though that version is officially EOL'd. So, in my opinion the least contentious way to go would be to have a set of instructions that inform the end user to install the JDK or JRE of their choice, subject to defined constraints. Then make PL/Java as painless as possible to install. This should not be a problem with larger organizations, since most use centrally-administered software configuration. Thanks. -- Guy Rouillier --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- Sent via pgsql-general mailing list ([hidden email] /user/SendEmail.jtp?type=nodenode=5819541i=0) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general If you reply to this email, your message will be added to the discussion below: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819541.html To unsubscribe from Why isn't Java support part of Postgresql core?, click here http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5819025code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3. NAML http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819545.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 09/17/2014 11:30 PM, Tom Lane wrote: But here's the *key* reason: if pl/java is failing to stay afloat as an external project, that is a terrible reason for pulling it into core. It suggests strongly that the manpower or interest to keep it going simply doesn't exist. This is really all that needs to be said, IMO. If it's not in core now, after *several years* of existing in various states of completeness on its own... it probably isn't going to be. If there can't be a solid deployment process *independent* of whatever state Java is in at any arbitrary moment, it has no business being in core. This is clearly a third-party module effort, as are many on PGXN. That is fine, honestly. What is wrong with something being an external module? Why does everything, including the kitchen sink of Java, need to be in core? It sounds like Mr. Cowwoc has some kind of issue with the maintainers of Pl/Java, and he should take it up with them. -- Shaun Thomas OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Thu, Sep 18, 2014 at 4:00 PM, cowwoc [via PostgreSQL] ml-node+s1045698n5819545...@n5.nabble.com wrote: Guy, As far as I understand, the concerns you brought up only apply to a public JRE. A private JRE is no different than any other library Postgresql links against. It's an implementation detail that does not affect your system-wide applications. Your vulnerability is no greater using an outdated private JRE than it is running an outdated version of Postgresql. All the Java vulnerabilities I am aware of have to do with running untrusted code on a public JRE (neither of which is being proposed). Lastly, nothing prevents you from upgrading the JRE directory yourself if you see fit (the JRE directory is a drop-in replacement with no external dependencies). It doesn't matter what brand of JRE you use, because only Postgresql uses it. Using the wrong brand will not cause your other applications to break (as it would if you were to replace a public JRE). Companies stick to Java 6 company-wide precisely because updating a public JRE would affect their other applications. Replacing a private JRE would not do that. only PostgreSQL uses it ... PostgreSQL doesn't use Java. 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. 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. 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. 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? 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 David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819553.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 09/18/2014 03:26 PM, David G Johnston wrote: 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 Amen. There are a trillion versions of Java in various states of deprecation, vendor, and target platform. This isn't Mono or .NET. I'd hate to be the dev team in charge of wrangling that mess into the PG build-farm. Ugh. -- Shaun Thomas OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 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.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Wed, Sep 17, 2014 at 11:42 PM, cowwoc cow...@bbs.darktech.org wrote: Tom, For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do. The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path) You've got it exactly backwards. 'core' should include as little as possible. In fact, many things that are in contrib (for example passwordcheck) today are holdovers from when standards of acceptance to contrib were lower. Rather than throwing the kitchen sink into core, IMSNO i would be a much better investment to spend efforts on expanding 'CREATE EXTENSION' so that it could do things like connect to internet repositories and install precomplied libraries. In lieu of that, if you wanted to make pl/java more accessible the first place I'd suggest going to the repository maintainers like pgdg and doing everything possible to help them get pl/java building and packaged. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 18-09-2014 17:58, cowwoc wrote: 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. 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. I've been reading all this stuff.. and I have one simple question: dll doesn't means dynamic linked library? Why does PostgreSQL needs to statically link to it? How does all those browsers link to different Java virtual machines? Don't they have a dynamic link library that makes a interface to them? Can't we use similar approach in PostgreSQL? So each one could use the desired JVM, without need to stick to this or that. Just my 2c... please forgive me if I'm throwing disparate words. Regards, Edson
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/15/14 1:30 PM, cowwoc wrote: Any chance you guys could help cleaning up the build/deploy process? This is a pretty big hurdle to overcome for new users. I'm glad to hear that PL/Java is still working well for some people. Last I saw it was stuck in a transition of the build system from make to maven, and the documentation was inconsistent either way. It looks like with a little non-coding help this could be cleared up. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/15/14 1:46 PM, Pavel Stehule wrote: I am strong sceptic. There is relative slow progress in JDBC driver, that is 100x more important project than PL/Java - so It is hard to believe, so there can be 3 developers, who start work on PL/Java. Stupid, completely offensive guess: Most Java programmers work in enterprise environments and are not allowed to or used to contributing to open source? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
2014-09-17 22:54 GMT+02:00 Peter Eisentraut pete...@gmx.net: On 9/15/14 1:46 PM, Pavel Stehule wrote: I am strong sceptic. There is relative slow progress in JDBC driver, that is 100x more important project than PL/Java - so It is hard to believe, so there can be 3 developers, who start work on PL/Java. Stupid, completely offensive guess: Most Java programmers work in enterprise environments and are not allowed to or used to contributing to open source? So what can be changed? Pavel
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 17/09/2014 5:05 PM, Pavel Stehule wrote: 2014-09-17 22:54 GMT+02:00 Peter Eisentraut pete...@gmx.net mailto:pete...@gmx.net: On 9/15/14 1:46 PM, Pavel Stehule wrote: I am strong sceptic. There is relative slow progress in JDBC driver, that is 100x more important project than PL/Java - so It is hard to believe, so there can be 3 developers, who start work on PL/Java. Stupid, completely offensive guess: Most Java programmers work in enterprise environments and are not allowed to or used to contributing to open source? So what can be changed? I don't think this is the case. There are tons of active open-source Java projects (more than C/C++). Having worked on a project that with both C and Java bits, I think the major hurdle to overcome is the build and deployment system. Over the past couple of years, the dominant Java build/deployment system has become Maven. Maven does a terrible job of handling non-Java code. When I say terrible, I mean terible! It was so bad that I eventually gave up and dropped the project altogether. Here is the problem description: http://stackoverflow.com/q/4171222/14731 And as you can see, the Maven authors closed the bug report as Won't Fix (at which point I finally gave up) If you can get over that hurdle, you should be able to get contributors by the dozens. I recommend using a mix of CMake and Apache Ant to build and only using Maven at the end to deploy. Gili
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 17/09/2014 4:51 PM, Peter Eisentraut wrote: On 9/15/14 1:30 PM, cowwoc wrote: Any chance you guys could help cleaning up the build/deploy process? This is a pretty big hurdle to overcome for new users. I'm glad to hear that PL/Java is still working well for some people. Last I saw it was stuck in a transition of the build system from make to maven, and the documentation was inconsistent either way. It looks like with a little non-coding help this could be cleared up. Peter, I think it would be much more productive to fix the deployment problem (instead of throwing more documentation at it). If the extension came bundled with Postgresql and was as easy to install as CREATE EXTENSION pljava then we wouldn't be having this discussion. Asking end-users to compile the project from source sounds like a non-starter to me. Gili -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/17/2014 2:50 PM, cowwoc wrote: I think it would be much more productive to fix the deployment problem (instead of throwing more documentation at it). If the extension came bundled with Postgresql and was as easy to install as CREATE EXTENSION pljava then we wouldn't be having this discussion. I believe a major issue is the JNI interface... even on a specific platform like RHEL6 there can be any of a rather wide range of different java's installed, openjdk 1.6, openjdk 1.7, or any of various Sun Java SE or EE builds, or even (ARRRGH) GCJ.. the JNI components need to be linked to a specific one of these to function properly. -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 17/09/2014 6:04 PM, John R Pierce [via PostgreSQL] wrote: On 9/17/2014 2:50 PM, cowwoc wrote: I think it would be much more productive to fix the deployment problem (instead of throwing more documentation at it). If the extension came bundled with Postgresql and was as easy to install as CREATE EXTENSION pljava then we wouldn't be having this discussion. I believe a major issue is the JNI interface... even on a specific platform like RHEL6 there can be any of a rather wide range of different java's installed, openjdk 1.6, openjdk 1.7, or any of various Sun Java SE or EE builds, or even (ARRRGH) GCJ.. the JNI components need to be linked to a specific one of these to function properly. Hi John, Can you be more specific? Are you talking about load-time linking against jvm.dll/so? Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819413.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/17/2014 3:07 PM, cowwoc wrote: Can you be more specific? Are you talking about load-time linking against jvm.dll/so? $JAVA_HOME/jre/lib/amd64/server/libjvm.so or whatever, yeah.the path of that relative to $JAVA_HOME is rather variable, depending on a lot of things, like 32 vs 64 bit JRE, x86 vs sparc/solaris vs AIX/power, and I think GCJ has a considerably different directory layout. Also... are the jni.h files the same or at least interchangable for the various flavors of Java? -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
As far as I understand it, this is the end-user's problem (to be documented) as opposed to a development problem. As far as I know, the jni.h files should be compatible with all other JDKs on the same platforms so you only need to release one DLL/SO per platforms (like you would if this was plain C) and it is then up to the user to make sure the Postgres process has the right JRE DLL/SO in its PATH. This shouldn't be too technically difficult to pull off. Gili On 17/09/2014 6:26 PM, John R Pierce [via PostgreSQL] wrote: On 9/17/2014 3:07 PM, cowwoc wrote: Can you be more specific? Are you talking about load-time linking against jvm.dll/so? $JAVA_HOME/jre/lib/amd64/server/libjvm.so or whatever, yeah. the path of that relative to $JAVA_HOME is rather variable, depending on a lot of things, like 32 vs 64 bit JRE, x86 vs sparc/solaris vs AIX/power, and I think GCJ has a considerably different directory layout. Also... are the jni.h files the same or at least interchangable for the various flavors of Java? -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list ([hidden email] /user/SendEmail.jtp?type=nodenode=5819414i=0) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general If you reply to this email, your message will be added to the discussion below: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819414.html To unsubscribe from Why isn't Java support part of Postgresql core?, click here http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5819025code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3. NAML http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819419.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/17/2014 5:02 PM, cowwoc wrote: As far as I understand it, this is the end-user's problem (to be documented) as opposed to a development problem. As far as I know, the jni.h files should be compatible with all other JDKs on the same platforms so you only need to release one DLL/SO per platforms (like you would if this was plain C) and it is then up to the user to make sure the Postgres process has the right JRE DLL/SO in its PATH. This shouldn't be too technically difficult to pull off. right. wait, which user?the java user/developer who typically hasn't a clue how system-level stuff functions or operates, or the postgresql database administrator, who probably hasn't a clue how java works internally ? -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
John R Pierce pie...@hogranch.com writes: On 9/17/2014 5:02 PM, cowwoc wrote: This shouldn't be too technically difficult to pull off. right. wait, which user?the java user/developer who typically hasn't a clue how system-level stuff functions or operates, or the postgresql database administrator, who probably hasn't a clue how java works internally ? There are a number of reasons why this (pl/java in core) isn't likely to happen; one being that I think a good fraction of the core PG developers fall into the haven't a clue how java works internally camp. But here's the *key* reason: if pl/java is failing to stay afloat as an external project, that is a terrible reason for pulling it into core. It suggests strongly that the manpower or interest to keep it going simply doesn't exist. Making it part of the core distribution would not fix that, and moreover it would demand attention from PG core developers who are not particularly motivated or capable to do anything with it. If you feel that pl/java isn't sufficiently well maintained, the short answer is that you should get involved with it as it is. In the end, open source is all about scratch your own itch. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
Tom, For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do. The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path). Gili On 18/09/2014 12:31 AM, Tom Lane-2 [via PostgreSQL] wrote: John R Pierce [hidden email] /user/SendEmail.jtp?type=nodenode=5819443i=0 writes: On 9/17/2014 5:02 PM, cowwoc wrote: This shouldn't be too technically difficult to pull off. right. wait, which user?the java user/developer who typically hasn't a clue how system-level stuff functions or operates, or the postgresql database administrator, who probably hasn't a clue how java works internally ? There are a number of reasons why this (pl/java in core) isn't likely to happen; one being that I think a good fraction of the core PG developers fall into the haven't a clue how java works internally camp. But here's the *key* reason: if pl/java is failing to stay afloat as an external project, that is a terrible reason for pulling it into core. It suggests strongly that the manpower or interest to keep it going simply doesn't exist. Making it part of the core distribution would not fix that, and moreover it would demand attention from PG core developers who are not particularly motivated or capable to do anything with it. If you feel that pl/java isn't sufficiently well maintained, the short answer is that you should get involved with it as it is. In the end, open source is all about scratch your own itch. regards, tom lane -- Sent via pgsql-general mailing list ([hidden email] /user/SendEmail.jtp?type=nodenode=5819443i=1) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general If you reply to this email, your message will be added to the discussion below: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819443.html To unsubscribe from Why isn't Java support part of Postgresql core?, click here http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5819025code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3. NAML http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819445.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Wed, Sep 17, 2014 at 9:42 PM, cowwoc cow...@bbs.darktech.org wrote: Tom, For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do. The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path). But what the core team has done is provide a pretty stable interface for getting to that point. The extension interface is well documented and quite stable IME. If the pl/java project can't get it to a point where you can make make install, then I don't see what would possibly benefit from getting into core. But if they get to that point then it can be on pgxn and you could install it with a pgxn client installation tool that would make things easy. Gili On 18/09/2014 12:31 AM, Tom Lane-2 [via PostgreSQL] wrote: John R Pierce [hidden email] http://user/SendEmail.jtp?type=nodenode=5819443i=0 writes: On 9/17/2014 5:02 PM, cowwoc wrote: This shouldn't be too technically difficult to pull off. right. wait, which user?the java user/developer who typically hasn't a clue how system-level stuff functions or operates, or the postgresql database administrator, who probably hasn't a clue how java works internally ? There are a number of reasons why this (pl/java in core) isn't likely to happen; one being that I think a good fraction of the core PG developers fall into the haven't a clue how java works internally camp. But here's the *key* reason: if pl/java is failing to stay afloat as an external project, that is a terrible reason for pulling it into core. It suggests strongly that the manpower or interest to keep it going simply doesn't exist. Making it part of the core distribution would not fix that, and moreover it would demand attention from PG core developers who are not particularly motivated or capable to do anything with it. If you feel that pl/java isn't sufficiently well maintained, the short answer is that you should get involved with it as it is. In the end, open source is all about scratch your own itch. regards, tom lane -- Sent via pgsql-general mailing list ([hidden email] http://user/SendEmail.jtp?type=nodenode=5819443i=1) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- If you reply to this email, your message will be added to the discussion below: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819443.html To unsubscribe from Why isn't Java support part of Postgresql core?, click here. NAML http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: Re: Why isn't Java support part of Postgresql core? http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819445.html Sent from the PostgreSQL - general mailing list archive http://postgresql.1045698.n5.nabble.com/PostgreSQL-general-f1843780.html at Nabble.com. -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 16 September 2014 03:07, David G Johnston david.g.johns...@gmail.com wrote: cowwoc wrote On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote: On 09/15/2014 11:49 AM, cowwoc wrote: I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be good enough). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do. Gili I've seen too many good java developers write too much terrible database-oriented code. If they are good with db and sql, plpgsql will not be a problem to learn. lup, Then does Postgresql support languages other than pl/pgsql? I'm not trying to tear down pl/pgsql, simply pointing out that there is strong demand for other languages as well. And to answer Pavel's earlier point: the lack of developers getting behind pl/java and JDBC driver does not equate the lack of demand for those tools. For every one person contributing patches, there are 1000s who do not but are more than happy to use the finished work. Gili I'm singing with the choir here but getting some of those thousand bodies contributing to both pl/java and existing or next generation Jdbc drivers would be nice. What do you mean by the next generation? - Szymon
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Mon, Sep 15, 2014 at 8:22 AM, cowwoc cow...@bbs.darktech.org wrote: I took a look at the PL/Java project and it looked both incomplete and dead, yet other languages like Javascript are taking off. I would have expected to see very strong support for Java because it's the most frequently used language on the server-side. Because no person or company has been motivated to push it so far. Why isn't this a core language supported alongside SQL, Perl and Python as part of the core project? I don't know about Perl, but the PL/Python language is somewhat neglected as well (though has been slightly improving recently). It's there because it was already merged ages ago. By today's quality standards, I believe it would not be accepted into PostgreSQL core. Regards, Marti -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Sun, Sep 14, 2014 at 10:22 PM, cowwoc cow...@bbs.darktech.org wrote: Hi, Out of curiosity, why is Postgresql's Java support so poor? I am specifically looking for the ability to write triggers in Java. Because it hasn't been a priority of contributors. This is how non-single-vendor open source projects work: people decide what is important to them and do the work required. If something gets neglected then I guess it wasn't really important. I took a look at the PL/Java project and it looked both incomplete and dead, yet other languages like Javascript are taking off. I would have expected to see very strong support for Java because it's the most frequently used language on the server-side. I think Javascript is taking off because JSON is taking off. The problem with Java is that while there are plenty of use cases for it in the db, it isn't something which there are *common* use cases for. What's going on? Why isn't this a core language supported alongside SQL, Perl and Python as part of the core project? I have a few questions on this, the answers of which may help answer your question: 1. How well does having a server-side JVM work, resource-wise, when you have a forked process model like PostgreSQL? Does having the additional JVM's pose performance and competition for resources that lighter languages would not? 2. What is your specific use case for a trigger in Java?
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Sun, 14 Sep 2014 22:22:21 -0700 (PDT) cowwoc cow...@bbs.darktech.org wrote: Out of curiosity, why is Postgresql's Java support so poor? To trampoline off what others have said: it gets implemented and maintained if people want/need it. But I feel like I have a little more insight into _why_ people aren't taking the effort, based on experience at my last job. We were interested in both pl/Java and pl/PHP. In theory, both of those would allow us to leverage both existing codebases and existing developer skills. We were looking at taking an active role in maintainership of these two languages to facilitate our use. In practice, the amount of code in existing code bases that would be reused for stored procedures turned out to be very low. Additionally, the number of developers who had difficulty adapting to plPGSQL programming was 0. As a result, we found that, in practice, the existing pl/SQL and plPGSQL were _good_enough_ and there was so little benefit from using other languages that we couldn't justify the effort of ensuring they worked consistently. From a meta standpoint, it feels like pl/Java and others are really neat ideas that simply aren't _necessary_ (although they're nice to have). When it comes down to work done for employer, it was just less effort to succeed by going the route of using the existing plSQL/plPGSQL, and employers are all about less money spent to accomplish the goal. Other people may have other opinions or stories or whatever. That's mine. -- Bill Moran I need your help to succeed: http://gamesbybill.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 9/15/14, Chris Travers chris.trav...@gmail.com wrote: On Sun, Sep 14, 2014 at 10:22 PM, cowwoc cow...@bbs.darktech.org wrote: Out of curiosity, why is Postgresql's Java support so poor? I am specifically looking for the ability to write triggers in Java. Because it hasn't been a priority of contributors. This is how non-single-vendor open source projects work: people decide what is important to them and do the work required. If something gets neglected then I guess it wasn't really important. What's going on? Why isn't this a core language supported alongside SQL, Perl and Python as part of the core project? I have a few questions on this, the answers of which may help answer your question: 1. How well does having a server-side JVM work, resource-wise, when you have a forked process model like PostgreSQL? Does having the additional JVM's pose performance and competition for resources that lighter languages would not? So eliminate JVM startup overhead by running (one or more instances of) JVM as a daemon, using nailgun : http://en.wikipedia.org/wiki/Java_performance#Startup_time http://martiansoftware.com/nailgun/ For low overhead (trigger) scripts, JVM startup overhead means order of magnitude(s) slow down - so nailgun means a massive speedup. Nailgun does not have multi-user security separation. Although if this is for a corporate project, adding such security with Unix domain sockets ought be very straightforward (cite is only a private email discussion I had with nailgun's author some years ago, where we concluded this should not be difficult to implement per se). 2. What is your specific use case for a trigger in Java? Excellent question. Good luck, Zenaan -- Banned for life from Debian, for suggesting Debian's CoC (Code of Conduct) is being swung in our faces a little too vigorously. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15/09/2014 08:22, cowwoc wrote: Hi, Out of curiosity, why is Postgresql's Java support so poor? I am specifically looking for the ability to write triggers in Java. I took a look at the PL/Java project and it looked both incomplete and dead, yet other languages like Javascript are taking off. I would have expected to see very strong support for Java because it's the most frequently used language on the server-side. This is far from dead. I works perfectly with java 1.7 and postgresql 9.3 , but you need maybe a little bit more extra homework + some skills with maven. If i managed to build this on a FreeBSD machine, in linux it should a piece of cake. The docs suck, granted, but the community is very much alive and helpful. We use it for production environment. We had some really complex Java code, that we were unwilling to port to pl/pgsql, therefore we gave pl/java a try. It was worth it. + it has proven to be really stable. No JVM crashes after 2 years in production. What's going on? Why isn't this a core language supported alongside SQL, Perl and Python as part of the core project? Thanks, Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Achilleas Mantzios Head of IT DEV IT DEPT Dynacom Tankers Mgmt -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15/09/14 13:30, Achilleas Mantzios wrote: This is far from dead. I works perfectly with java 1.7 and postgresql 9.3 , but you need maybe a little bit more extra homework + some skills with maven. If i managed to build this on a FreeBSD machine, in linux it should a piece of cake. The docs suck, granted, but the community is very much alive and helpful. We use it for production environment. We had some really complex Java code, that we were unwilling to port to pl/pgsql, therefore we gave pl/java a try. It was worth it. + it has proven to be really stable. No JVM crashes after 2 years in production. +1 for that; we are too. -- Tim Clarke -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Mon, Sep 15, 2014 at 6:03 AM, Chris Travers chris.trav...@gmail.com wrote:
On Sun, Sep 14, 2014 at 10:22 PM, cowwoc cow...@bbs.darktech.org wrote:
Hi,
Out of curiosity, why is Postgresql's Java support so poor? I am
specifically looking for the ability to write triggers in Java.
Because it hasn't been a priority of contributors. This is how
non-single-vendor open source projects work: people decide what is important
to them and do the work required. If something gets neglected then I guess
it wasn't really important.
I took a look at the PL/Java project and it looked both incomplete and
dead,
yet other languages like Javascript are taking off. I would have expected
to
see very strong support for Java because it's the most frequently used
language on the server-side.
I think Javascript is taking off because JSON is taking off. The problem
with Java is that while there are plenty of use cases for it in the db, it
isn't something which there are *common* use cases for.
JSON is part of it but there's more. javascript is a language
designed for embedding and so makes very little assumptions about the
host environment. It doesn't use threads which is particularly nice
and that (along with the highly asynchronous nature of the language)
has influenced developer culture and library design. It doesn't
expose things which are dubious to do in a stored procedure and the pl
wrapper can expose such things in a proper API or not at all. Java
OTOH exposes (being a systems language) anything and everything. The
architecture of having the GC embedded inside a postgres process is
awkward to say the least. Don't get me wrong: pl/java works
beautifully if you know what you're doing but you have to approach
things as a minimalist from the java point of view if you want things
to work well and minimalism is not, uh, endemic to the java culture.
There's more: plv8 relies in BSD licensed c++ runtime from google.
It's pretty self contained and friendly. Java is provided by Oracle
('nuff said) with a complicated license that I don't understand TBH.
This doesn't necessarily argue against 'core support' but it's
something to think about.
So I'd argue plv8 has a much better case of being put 'in core', but
I'd argue that neither of them should be. Why? The core team is
already supporting enough code and it seems better to make the
extension framework more robust so that users have a easier route to
pulling in 3rd party libraries than they currently do.
merlin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Mon, Sep 15, 2014 at 11:23 PM, Merlin Moncure mmonc...@gmail.com wrote: So I'd argue plv8 has a much better case of being put 'in core', but I'd argue that neither of them should be. Why? The core team is already supporting enough code and it seems better to make the extension framework more robust so that users have a easier route to pulling in 3rd party libraries than they currently do. It is worth noting that v8 newer than versions 3.14 (if I recall correctly) has introduced many API breakages making plv8 incompatible in those cases with newer versions, making it rather harder to integrate into core with a long-term vision: https://apps.fedoraproject.org/packages/v8 Regards, -- Michael -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Tue, Sep 16, 2014 at 1:43 AM, Michael Paquier michael.paqu...@gmail.com wrote: https://apps.fedoraproject.org/packages/v8 Forgot to add that this is probably one of the reasons why Fedora sticks to this version. -- Michael -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
Hi guys, Any chance you guys could help cleaning up the build/deploy process? This is a pretty big hurdle to overcome for new users. Gili On 15/09/2014 8:55 AM, Tim Clarke [via PostgreSQL] wrote: On 15/09/14 13:30, Achilleas Mantzios wrote: This is far from dead. I works perfectly with java 1.7 and postgresql 9.3 , but you need maybe a little bit more extra homework + some skills with maven. If i managed to build this on a FreeBSD machine, in linux it should a piece of cake. The docs suck, granted, but the community is very much alive and helpful. We use it for production environment. We had some really complex Java code, that we were unwilling to port to pl/pgsql, therefore we gave pl/java a try. It was worth it. + it has proven to be really stable. No JVM crashes after 2 years in production. +1 for that; we are too. -- Tim Clarke -- Sent via pgsql-general mailing list ([hidden email] /user/SendEmail.jtp?type=nodenode=5819054i=0) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general If you reply to this email, your message will be added to the discussion below: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819054.html To unsubscribe from Why isn't Java support part of Postgresql core?, click here http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5819025code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3. NAML http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819084.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15/09/2014 7:03 AM, Chris Travers wrote: I have a few questions on this, the answers of which may help answer your question: 1. How well does having a server-side JVM work, resource-wise, when you have a forked process model like PostgreSQL? Does having the additional JVM's pose performance and competition for resources that lighter languages would not? I don't think this is really a concern when connection pooling is used (otherwise you end up creating a new JVM per connection which is indeed problematic). 2. What is your specific use case for a trigger in Java? The main drivers are: 1. Not having to learn yet another language. I find the expressiveness and readability of the other scripting languages very clunky compared to Java. 2. Ease of porting triggers across databases. The only thing that really changes across databases is how triggers interact with input/output parameters. The main body remains the same (thanks to JDBC). This is quasi portability in the sense that the underlying SQL is itself quasi portable, but I find it a much more compelling approach than having to rewrite the triggers for each database type. Gili
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15/09/2014 7:58 AM, Bill Moran wrote: On Sun, 14 Sep 2014 22:22:21 -0700 (PDT) cowwoc cow...@bbs.darktech.org wrote: Out of curiosity, why is Postgresql's Java support so poor? To trampoline off what others have said: it gets implemented and maintained if people want/need it. But I feel like I have a little more insight into _why_ people aren't taking the effort, based on experience at my last job. We were interested in both pl/Java and pl/PHP. In theory, both of those would allow us to leverage both existing codebases and existing developer skills. We were looking at taking an active role in maintainership of these two languages to facilitate our use. In practice, the amount of code in existing code bases that would be reused for stored procedures turned out to be very low. Additionally, the number of developers who had difficulty adapting to plPGSQL programming was 0. As a result, we found that, in practice, the existing pl/SQL and plPGSQL were _good_enough_ and there was so little benefit from using other languages that we couldn't justify the effort of ensuring they worked consistently. From a meta standpoint, it feels like pl/Java and others are really neat ideas that simply aren't _necessary_ (although they're nice to have). When it comes down to work done for employer, it was just less effort to succeed by going the route of using the existing plSQL/plPGSQL, and employers are all about less money spent to accomplish the goal. Other people may have other opinions or stories or whatever. That's mine. I'm very glad you posted this because I was thinking the same but needed someone to reinforce my views. pl/pgsql is beginning to look like the lesser evil to getting pl/java to work. Sad but true. I strongly believe that pl/java would catapult the expressiveness of triggers to a new level, but getting this off the ground will require the concerted effort of 2-3 dedicated developers. Gili -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
2014-09-15 19:34 GMT+02:00 cowwoc cow...@bbs.darktech.org: On 15/09/2014 7:03 AM, Chris Travers wrote: I have a few questions on this, the answers of which may help answer your question: 1. How well does having a server-side JVM work, resource-wise, when you have a forked process model like PostgreSQL? Does having the additional JVM's pose performance and competition for resources that lighter languages would not? I don't think this is really a concern when connection pooling is used (otherwise you end up creating a new JVM per connection which is indeed problematic). 2. What is your specific use case for a trigger in Java? The main drivers are: 1. Not having to learn yet another language. I find the expressiveness and readability of the other scripting languages very clunky compared to Java. PLpgSQL is different, it is based on Ada language 1. Ease of porting triggers across databases. The only thing that really changes across databases is how triggers interact with input/output parameters. The main body remains the same (thanks to JDBC). This is quasi portability in the sense that the underlying SQL is itself quasi portable, but I find it a much more compelling approach than having to rewrite the triggers for each database type. any time plpgsql will be faster then Java probably due a type compatibility with Postgres and execution as inprocess There is a few task, that can be done in database, that will be faster in PL/Java than PL/pgSQL Regards Pavel Gili
Re: [GENERAL] Why isn't Java support part of Postgresql core?
2014-09-15 19:37 GMT+02:00 cowwoc cow...@bbs.darktech.org: On 15/09/2014 7:58 AM, Bill Moran wrote: On Sun, 14 Sep 2014 22:22:21 -0700 (PDT) cowwoc cow...@bbs.darktech.org wrote: Out of curiosity, why is Postgresql's Java support so poor? To trampoline off what others have said: it gets implemented and maintained if people want/need it. But I feel like I have a little more insight into _why_ people aren't taking the effort, based on experience at my last job. We were interested in both pl/Java and pl/PHP. In theory, both of those would allow us to leverage both existing codebases and existing developer skills. We were looking at taking an active role in maintainership of these two languages to facilitate our use. In practice, the amount of code in existing code bases that would be reused for stored procedures turned out to be very low. Additionally, the number of developers who had difficulty adapting to plPGSQL programming was 0. As a result, we found that, in practice, the existing pl/SQL and plPGSQL were _good_enough_ and there was so little benefit from using other languages that we couldn't justify the effort of ensuring they worked consistently. From a meta standpoint, it feels like pl/Java and others are really neat ideas that simply aren't _necessary_ (although they're nice to have). When it comes down to work done for employer, it was just less effort to succeed by going the route of using the existing plSQL/plPGSQL, and employers are all about less money spent to accomplish the goal. Other people may have other opinions or stories or whatever. That's mine. I'm very glad you posted this because I was thinking the same but needed someone to reinforce my views. pl/pgsql is beginning to look like the lesser evil to getting pl/java to work. Sad but true. I strongly believe that pl/java would catapult the expressiveness of triggers to a new level, but getting this off the ground will require the concerted effort of 2-3 dedicated developers. I am strong sceptic. There is relative slow progress in JDBC driver, that is 100x more important project than PL/Java - so It is hard to believe, so there can be 3 developers, who start work on PL/Java. Regards Pavel Gili -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
Hi Pavel, On 15/09/2014 1:40 PM, Pavel Stehule wrote: The main drivers are: 1. Not having to learn yet another language. I find the expressiveness and readability of the other scripting languages very clunky compared to Java. PLpgSQL is different, it is based on Ada language I'm sure it's a very lovely language, but it is yet another language most people are not familiar with and will have to learn. 1. Ease of porting triggers across databases. The only thing that really changes across databases is how triggers interact with input/output parameters. The main body remains the same (thanks to JDBC). This is quasi portability in the sense that the underlying SQL is itself quasi portable, but I find it a much more compelling approach than having to rewrite the triggers for each database type. any time plpgsql will be faster then Java probably due a type compatibility with Postgres and execution as inprocess There is a few task, that can be done in database, that will be faster in PL/Java than PL/pgSQL I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be good enough). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do. Gili
Re: [GENERAL] Why isn't Java support part of Postgresql core?
2014-09-15 19:46 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com: 2014-09-15 19:37 GMT+02:00 cowwoc cow...@bbs.darktech.org: On 15/09/2014 7:58 AM, Bill Moran wrote: On Sun, 14 Sep 2014 22:22:21 -0700 (PDT) cowwoc cow...@bbs.darktech.org wrote: Out of curiosity, why is Postgresql's Java support so poor? To trampoline off what others have said: it gets implemented and maintained if people want/need it. But I feel like I have a little more insight into _why_ people aren't taking the effort, based on experience at my last job. We were interested in both pl/Java and pl/PHP. In theory, both of those would allow us to leverage both existing codebases and existing developer skills. We were looking at taking an active role in maintainership of these two languages to facilitate our use. In practice, the amount of code in existing code bases that would be reused for stored procedures turned out to be very low. Additionally, the number of developers who had difficulty adapting to plPGSQL programming was 0. As a result, we found that, in practice, the existing pl/SQL and plPGSQL were _good_enough_ and there was so little benefit from using other languages that we couldn't justify the effort of ensuring they worked consistently. From a meta standpoint, it feels like pl/Java and others are really neat ideas that simply aren't _necessary_ (although they're nice to have). When it comes down to work done for employer, it was just less effort to succeed by going the route of using the existing plSQL/plPGSQL, and employers are all about less money spent to accomplish the goal. Other people may have other opinions or stories or whatever. That's mine. I'm very glad you posted this because I was thinking the same but needed someone to reinforce my views. pl/pgsql is beginning to look like the lesser evil to getting pl/java to work. Sad but true. I strongly believe that pl/java would catapult the expressiveness of triggers to a new level, but getting this off the ground will require the concerted effort of 2-3 dedicated developers. I am strong sceptic. There is relative slow progress in JDBC driver, that is 100x more important project than PL/Java - so It is hard to believe, so there can be 3 developers, who start work on PL/Java. and I am not sure if Java as stored procedures is living technology, It was designed as esperanto, but it is supported only by Oracle after 14 years. Pavel Regards Pavel Gili -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 09/15/2014 11:49 AM, cowwoc wrote: Hi Pavel, On 15/09/2014 1:40 PM, Pavel Stehule wrote: The main drivers are: 1. Not having to learn yet another language. I find the expressiveness and readability of the other scripting languages very clunky compared to Java. PLpgSQL is different, it is based on Ada language I'm sure it's a very lovely language, but it is yet another language most people are not familiar with and will have to learn. 1. Ease of porting triggers across databases. The only thing that really changes across databases is how triggers interact with input/output parameters. The main body remains the same (thanks to JDBC). This is quasi portability in the sense that the underlying SQL is itself quasi portable, but I find it a much more compelling approach than having to rewrite the triggers for each database type. any time plpgsql will be faster then Java probably due a type compatibility with Postgres and execution as inprocess There is a few task, that can be done in database, that will be faster in PL/Java than PL/pgSQL I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be good enough). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do. Gili I've seen too many good java developers write too much terrible database-oriented code. If they are good with db and sql, plpgsql will not be a problem to learn.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15/09/2014 1:51 PM, Pavel Stehule [via PostgreSQL] wrote: and I am not sure if Java as stored procedures is living technology, It was designed as esperanto, but it is supported only by Oracle after 14 years. Pavel H2, HSQLDB, Derby all support Java triggers. Granted, we are not talking about MySQL or Oracle here, but these did not add Java triggers as an afterthought. Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819098.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
2014-09-15 19:49 GMT+02:00 cowwoc cow...@bbs.darktech.org: Hi Pavel, On 15/09/2014 1:40 PM, Pavel Stehule wrote: The main drivers are: 1. Not having to learn yet another language. I find the expressiveness and readability of the other scripting languages very clunky compared to Java. PLpgSQL is different, it is based on Ada language I'm sure it's a very lovely language, but it is yet another language most people are not familiar with and will have to learn. you need one day learning only .. it contains only necessary functionality for stored procedures, nothing more. It is like Java in 90 years - just simple 1. Ease of porting triggers across databases. The only thing that really changes across databases is how triggers interact with input/output parameters. The main body remains the same (thanks to JDBC). This is quasi portability in the sense that the underlying SQL is itself quasi portable, but I find it a much more compelling approach than having to rewrite the triggers for each database type. any time plpgsql will be faster then Java probably due a type compatibility with Postgres and execution as inprocess There is a few task, that can be done in database, that will be faster in PL/Java than PL/pgSQL I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be good enough). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do. I know a situation in Czech Republic well and in Europe little bit My estimation is about PostgreSQL applications 95% applications is wrote without stored procedures 4% applications is wrote with PL/pgSQL .9% is combination PL/pgSQL with PL/Perl or PL/Python (Perl is older with CPAN, Python is popular in GIS community) 0.01% has all other .. pl/v8 was used mainly for JSON manipulation, because this possibility was not in PG, PL/R, PL/Lua, PL/PHP, PL/v8 has very small user community For typical Java or Javascript users the stored procedures are devil still. Gili
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote: On 09/15/2014 11:49 AM, cowwoc wrote: I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be good enough). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do. Gili I've seen too many good java developers write too much terrible database-oriented code. If they are good with db and sql, plpgsql will not be a problem to learn. lup, Then does Postgresql support languages other than pl/pgsql? I'm not trying to tear down pl/pgsql, simply pointing out that there is strong demand for other languages as well. And to answer Pavel's earlier point: the lack of developers getting behind pl/java and JDBC driver does not equate the lack of demand for those tools. For every one person contributing patches, there are 1000s who do not but are more than happy to use the finished work. Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819104.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15/09/2014 2:12 PM, cowwoc wrote: On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote: On 09/15/2014 11:49 AM, cowwoc wrote: I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be good enough). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do. Gili I've seen too many good java developers write too much terrible database-oriented code. If they are good with db and sql, plpgsql will not be a problem to learn. lup, Then does Postgresql support languages other than pl/pgsql? I'm not trying to tear down pl/pgsql, simply pointing out that there is strong demand for other languages as well. And to answer Pavel's earlier point: the lack of developers getting behind pl/java and JDBC driver does not equate the lack of demand for those tools. For every one person contributing patches, there are 1000s who do not but are more than happy to use the finished work. Gili Then does was meant to read Then *why* does :) Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819105.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 09/15/2014 11:00 AM, Rob Sargent wrote: On 09/15/2014 11:49 AM, cowwoc wrote: Hi Pavel, On 15/09/2014 1:40 PM, Pavel Stehule wrote: The main drivers are: 1. Not having to learn yet another language. I find the expressiveness and readability of the other scripting languages very clunky compared to Java. Gili I've seen too many good java developers write too much terrible database-oriented code. If they are good with db and sql, plpgsql will not be a problem to learn. Agreed, plpgsql is SQL with Postgres extensions. I went down this road with plpythonu. I am comfortable in Python, so I thought it would be easier to write functions using plpythonu. I actually did this backwards. I had created a fairly complex function in plpgsql and I figured I could simplify by using plpythonu. I was well into it when I had realized I written more code in plpythonu than plpgsql and still was not close to completing it. I still use plpythonu but only when I need the dynamic nature of Python or really need to use some Python module. -- Adrian Klaver adrian.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15 September 2014 20:13, cowwoc cow...@bbs.darktech.org wrote: On 15/09/2014 2:12 PM, cowwoc wrote: On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote: On 09/15/2014 11:49 AM, cowwoc wrote: I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be good enough). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do. Gili I've seen too many good java developers write too much terrible database-oriented code. If they are good with db and sql, plpgsql will not be a problem to learn. lup, Then does Postgresql support languages other than pl/pgsql? I'm not trying to tear down pl/pgsql, simply pointing out that there is strong demand for other languages as well. And to answer Pavel's earlier point: the lack of developers getting behind pl/java and JDBC driver does not equate the lack of demand for those tools. For every one person contributing patches, there are 1000s who do not but are more than happy to use the finished work. Gili Then does was meant to read Then *why* does :) Gili Hi, you're right. But there is no other way to have this done than have someone done it. If there are no people interested in doing that it will not be done. Unfortunately. - Szymon
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On Mon, 15 Sep 2014 13:34:53 -0400 cowwoc cow...@bbs.darktech.org wrote: 2. What is your specific use case for a trigger in Java? The main drivers are: 1. Not having to learn yet another language. Bear in mind that DB programmers often know SQL. To me, and apparently to them, PL/pgsql seems closer to the already-known SQL than PL/JAVA. Besides that, PL/JAVA -which I honestly think is a great concept in itself- doesn't free you from learning yet another language if you are working with PHP, Python, Node.js, etc... In these cases, PL/pgsql is a safer bet. -- Alberto Cabello Sánchez albe...@unex.es -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
cowwoc wrote on 15.09.2014 19:55: H2, HSQLDB, Derby all support Java triggers. But only because they already live/run inside a JVM, so it's the natural choice of language. And H2 and Derby *only* support Java stored procedures. The main disadvantage I see with that is, that you can't just write a procedure (or trigger) with a simple (procedural) SQL Statement. Yyou need to compile it, package into a jar file and the add the jar file(s) to the classpath of the application (or the server process). This essentially means you need to restart your application or the server when you deploy a trigger. Hardly anyhting that you want to do in a production environment. Granted, we are not talking about MySQL or Oracle here, but these did not add Java triggers as an afterthought. MySQL does not have Java triggers (or procedures). -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why isn't Java support part of Postgresql core?
On 15/09/2014 3:50 PM, Thomas Kellerer [via PostgreSQL] wrote: cowwoc wrote on 15.09.2014 19:55: H2, HSQLDB, Derby all support Java triggers. But only because they already live/run inside a JVM, so it's the natural choice of language. And H2 and Derby *only* support Java stored procedures. The main disadvantage I see with that is, that you can't just write a procedure (or trigger) with a simple (procedural) SQL Statement. Yyou need to compile it, package into a jar file and the add the jar file(s) to the classpath of the application (or the server process). This essentially means you need to restart your application or the server when you deploy a trigger. Hardly anyhting that you want to do in a production environment. Thomas, That is a reasonable point, but there is no technical reason for requiring a restart. Typical implementations might require a restart because of ease of implementation but if you were to load each JAR into its own ClassLoader you could load/unload them without a restart. Granted this requires more work, but we're not inventing anything new here. This is how all major Java web servers work. Gili -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819136.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Re: [GENERAL] Why isn't Java support part of Postgresql core?
cowwoc wrote On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote: On 09/15/2014 11:49 AM, cowwoc wrote: I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be good enough). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do. Gili I've seen too many good java developers write too much terrible database-oriented code. If they are good with db and sql, plpgsql will not be a problem to learn. lup, Then does Postgresql support languages other than pl/pgsql? I'm not trying to tear down pl/pgsql, simply pointing out that there is strong demand for other languages as well. And to answer Pavel's earlier point: the lack of developers getting behind pl/java and JDBC driver does not equate the lack of demand for those tools. For every one person contributing patches, there are 1000s who do not but are more than happy to use the finished work. Gili I'm singing with the choir here but getting some of those thousand bodies contributing to both pl/java and existing or next generation Jdbc drivers would be nice. And that doesn't just mean code - updated articles and buildfarm animals are just a couple of resources that could be contributed. If nothing else make the projects look more lively than current even if the code itself is unchanged. If you know SQL and Java then you have enough skill and experience to use the proper tool for the job instead of turning everything in a java-nail for your java-hammer. Most everything that can be done in this arena can be done outside of core. There may be things a pure java developer would like the core to provide that would require C programming skills but likely, as mentioned, those support parts would benefit more than only Java and would be embraced by the core community. I'll agree, though without personal experience, that a java trigger is more portable than a pl/pgsql one. At the same time users utilizing PostgreSQL to its fullest are going to have significant portability issues since custom data types and aggregates, arrays, and other advanced features that are used by applications are not all that portable. I think we'd love to help make it easier for java-only shops to target PostgreSQL as their backend but there has to be some payoff to the people putting up the resources to make it happen. That is much more likely to occur because someone with a huge installed base of java code wants to use PostgreSQL to enhance their product. In that case adding more core features to entice those people to come over seems a better approach than devoting resources to adding capabilities that may not be strongly accepted nor fully useful because the people writing them are not sufficiently invested in the outcome. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819145.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
