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

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?

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.

On Mon, Sep 15, 2014 at 8:22 AM, cowwoc <cowwoc@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

On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
cowwoc <cowwoc@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

On 9/15/14, Chris Travers <chris.travers@gmail.com> wrote:
> On Sun, Sep 14, 2014 at 10:22 PM, cowwoc <cowwoc@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.

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

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

On Mon, Sep 15, 2014 at 6:03 AM, Chris Travers <chris.travers@gmail.com> wrote:
>
>
> On Sun, Sep 14, 2014 at 10:22 PM, cowwoc <cowwoc@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

On Mon, Sep 15, 2014 at 11:23 PM, Merlin Moncure <mmoncure@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

On Tue, Sep 16, 2014 at 1:43 AM, Michael Paquier
<michael.paquier@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

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])
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.
NAML

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?

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

On 15/09/2014 7:58 AM, Bill Moran wrote:
> On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
> cowwoc <cowwoc@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

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

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

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.

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

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.klaver@aklaver.com

On Mon, 15 Sep 2014 13:34:53 -0400
cowwoc <cowwoc@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
<alberto@unex.es>

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
classpathof 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).

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.

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.

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?

2014-09-17 22:54 GMT+02:00 Peter Eisentraut <peter_e@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?

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

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

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

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])
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.
NAML

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

John R Pierce <pierce@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

John R Pierce <[hidden email]> 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])
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

On Wed, Sep 17, 2014 at 9:42 PM, cowwoc <cowwoc@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.

Chris,

On 18/09/2014 1:07 AM, Chris Travers wrote:

On Wed, Sep 17, 2014 at 9:42 PM, cowwoc <cowwoc@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

cowwoc wrote
> Chris,
>
> On 18/09/2014 1:07 AM, Chris Travers wrote:
>> On Wed, Sep 17, 2014 at 9:42 PM, cowwoc <

> cowwoc@.darktech

>
> > <mailto:

> cowwoc@.darktech

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

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

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])
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.
NAML

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

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

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

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
onein a quick google search. 





--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

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.

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

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])
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.
NAML

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
sthomas@optionshouse.com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

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
sthomas@optionshouse.com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

​ "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

On Wed, Sep 17, 2014 at 11:42 PM, cowwoc <cowwoc@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

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.

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?

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

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?

2014-09-15 9:22 GMT+04:00 cowwoc <cowwoc@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.