Why isn't Java support part of Postgresql core?

[cowwoc]

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.

[Marti Raudsepp]

Post by cowwoc
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.

Post by cowwoc
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

[Chris Travers]

Post by cowwoc
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.

Post by cowwoc
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.

Post by cowwoc
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?

[Zenaan Harkness]

Post by Chris Travers

Post by cowwoc
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.

Post by cowwoc
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
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).

Post by Chris Travers
2. What is your specific use case for a trigger in Java?

Excellent question.

Good luck,
Zenaan

[Merlin Moncure]

Post by Chris Travers

Post by cowwoc
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.

Post by cowwoc
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

[Michael Paquier]

Post by Merlin Moncure
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 Paquier]

On Tue, Sep 16, 2014 at 1:43 AM, Michael Paquier

Post by Michael Paquier
https://apps.fedoraproject.org/packages/v8

Forgot to add that this is probably one of the reasons why Fedora
sticks to this version.

[cowwoc]

Post by Chris Travers
I have a few questions on this, the answers of which may help answer
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).

Post by Chris Travers
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

[Pavel Stehule]

Post by Chris Travers
I have a few questions on this, the answers of which may help answer your
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?
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

Post by Chris Travers
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

Post by Chris Travers
Gili

[cowwoc]

Hi Pavel,

Post by cowwoc
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.

Post by cowwoc
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

[Rob Sargent]

Post by cowwoc
Hi Pavel,

Post by cowwoc
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.

Post by cowwoc
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.

[cowwoc]

Post by Rob Sargent

Post by cowwoc
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.

[David G Johnston]

Post by cowwoc

Post by Rob Sargent

Post by cowwoc
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.

[Szymon Guz]

Post by David G Johnston

Post by cowwoc

Post by Rob Sargent

Post by cowwoc
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

[cowwoc]

Post by cowwoc

Post by Rob Sargent

Post by cowwoc
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.

[Szymon Guz]

Post by cowwoc
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

[Adrian Klaver]

Post by Rob Sargent

Post by cowwoc
Hi Pavel,

Post by cowwoc
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.

[Pavel Stehule]

Post by cowwoc
Hi Pavel,

Post by cowwoc
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

Post by cowwoc

Post by cowwoc
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.

Post by cowwoc
Gili

[Alberto Cabello Sánchez]

On Mon, 15 Sep 2014 13:34:53 -0400

Post by cowwoc

Post by Chris Travers
2. What is your specific use case for a trigger in Java?

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.

[Bill Moran]

On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)

Post by cowwoc
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.

Post by cowwoc
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

[cowwoc]

Post by Bill Moran
On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)

Post by cowwoc
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

[Pavel Stehule]

Post by cowwoc

Post by Bill Moran
On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)

Post by cowwoc
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

Post by cowwoc
Gili
--
http://www.postgresql.org/mailpref/pgsql-general

[Pavel Stehule]

Post by Pavel Stehule

Post by cowwoc

Post by Bill Moran
On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)

Post by cowwoc
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

Post by Pavel Stehule
Regards
Pavel

Post by cowwoc
Gili
--
http://www.postgresql.org/mailpref/pgsql-general

[cowwoc]

Post by Pavel Stehule
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.

[Thomas Kellerer]

Post by cowwoc
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.

Post by cowwoc
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]

Post by Thomas Kellerer

Post by cowwoc
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.

[Peter Eisentraut]

Post by Pavel Stehule
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?

[Pavel Stehule]

Post by Peter Eisentraut

Post by Pavel Stehule
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

[cowwoc]

Post by Peter Eisentraut

Post by Pavel Stehule
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 terrrrrible! 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

[Achilleas Mantzios]

Post by cowwoc
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.

Post by cowwoc
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

[Tim Clarke]

Post by Achilleas Mantzios
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.

[cowwoc]

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

Post by Achilleas Mantzios

Post by Achilleas Mantzios
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.

Post by Achilleas Mantzios
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=node&node=5819054&i=0>)
http://www.postgresql.org/mailpref/pgsql-general
------------------------------------------------------------------------
If you reply to this email, your message will be added to the
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_code&node=5819025&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3>.
NAML
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=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.

[Peter Eisentraut]

Post by cowwoc
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.

[cowwoc]

Post by Peter Eisentraut

Post by cowwoc
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

[John R Pierce]

Post by cowwoc
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

[cowwoc]

Post by John R Pierce

Post by cowwoc
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.

[John R Pierce]

Post by cowwoc
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

[cowwoc]

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

Post by cowwoc
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=node&node=5819414&i=0>)
http://www.postgresql.org/mailpref/pgsql-general
------------------------------------------------------------------------
If you reply to this email, your message will be added to the
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_code&node=5819025&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3>.
NAML
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=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.

[John R Pierce]

Post by cowwoc
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

[Tom Lane]

Post by Szymon Guz

Post by cowwoc
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

[cowwoc]

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

John R Pierce <[hidden email]

Post by Szymon Guz

Post by cowwoc
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=node&node=5819443&i=1>)
http://www.postgresql.org/mailpref/pgsql-general
------------------------------------------------------------------------
If you reply to this email, your message will be added to the
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_code&node=5819025&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3>.
NAML
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=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.

[Chris Travers]

Post by cowwoc
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.

Post by cowwoc
Gili
John R Pierce <[hidden email]

Post by Szymon Guz

Post by cowwoc
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=node&node=5819443&i=1>)
http://www.postgresql.org/mailpref/pgsql-general
------------------------------
If you reply to this email, your message will be added to the discussion
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_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=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.

[cowwoc]

Chris,

Post by cowwoc
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

[Misa Simic]

Post by cowwoc
Chris,

Post by cowwoc
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

[David G Johnston]

Post by cowwoc
Chris,

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

[John R Pierce]

Post by David G Johnston
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

[Szymon Guz]

Post by David G Johnston
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?

[cowwoc]

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

Post by John R Pierce

Post by David G Johnston
What distributions of JRE are available on the Windows platform and

which

Post by David G Johnston
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=node&node=5819509&i=0>)
http://www.postgresql.org/mailpref/pgsql-general
------------------------------------------------------------------------
If you reply to this email, your message will be added to the
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_code&node=5819025&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3>.
NAML
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=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.

[John R Pierce]

Post by cowwoc
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

[Szymon Guz]

Post by John R Pierce

Post by cowwoc
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

[John R Pierce]

Post by Szymon Guz
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

[cowwoc]

Post by John R Pierce

Post by Szymon Guz
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.

[John R Pierce]

Post by cowwoc

Post by John R Pierce

Post by Szymon Guz
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

[cowwoc]

Post by John R Pierce

Post by cowwoc
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.

[John R Pierce]

Post by cowwoc
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...

Post by cowwoc
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

[cowwoc]

Post by John R Pierce

Post by cowwoc
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

Post by cowwoc
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...

Post by cowwoc
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.

[Guy Rouillier]

Post by cowwoc
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

[cowwoc]

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

Post by Guy Rouillier

Post by cowwoc
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

Post by cowwoc
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=node&node=5819541&i=0>)
http://www.postgresql.org/mailpref/pgsql-general
------------------------------------------------------------------------
If you reply to this email, your message will be added to the
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_code&node=5819025&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3>.
NAML
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=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.

[David G Johnston]

On Thu, Sep 18, 2014 at 4:00 PM, cowwoc [via PostgreSQL] <

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.

[Shaun Thomas]

Post by David G Johnston
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
***@optionshouse.com

______________________________________________

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

[cowwoc]

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

[Edson Carlos Ericksson Richter]

Post by cowwoc

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

[Szymon Guz]

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

Post by David G Johnston
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

[cowwoc]

I am beginning to feel like people are putting words in my mouth :)

Post by Szymon Guz
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.

Post by Szymon Guz
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.

Post by Szymon Guz
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.

Post by Szymon Guz
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.

Post by Szymon Guz
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.

Post by Szymon Guz
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

[Szymon Guz]

Post by cowwoc
I am beginning to feel like people are putting words in my mouth :)
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.

Post by cowwoc
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.

Post by cowwoc
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

[cowwoc]

Post by Szymon Guz
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.

Post by Szymon Guz
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.

Post by Szymon Guz

Post by Szymon Guz
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.

Post by Szymon Guz
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

[Chris Travers]

These are minor nitpicks but they address significant questions about the
scope of core.

Post by cowwoc
I am beginning to feel like people are putting words in my mouth :)
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.

Post by cowwoc
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.
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.

[cowwoc]

Post by David G Johnston
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)

Post by David G Johnston
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.

[Merlin Moncure]

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

[Shaun Thomas]

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

______________________________________________

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

[Dmitriy Igrishin]

Post by cowwoc
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? :-)

[Rob Sargent]

Post by cowwoc
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!

[Chris Travers]

Post by Dmitriy Igrishin

Post by cowwoc
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*

Post by Dmitriy Igrishin
--
// Dmitriy.