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

On 18 September 2014 22:58, cowwoc <cowwoc(at)bbs(dot)darktech(dot)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 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?

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.

Szymon