Re: Why isn't Java support part of Postgresql core?

On 18 September 2014 22:58, cowwoc <cowwoc@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).