Why isn't Java support part of Postgresql core?

On Mon, Sep 15, 2014 at 8:22 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

I took a look at the PL/Java project and it looked both incomplete and dead,
yet other languages like Javascript are taking off. I would have expected to
see very strong support for Java because it's the most frequently used
language on the server-side.

Because no person or company has been motivated to push it so far.

Why isn't this a core language supported alongside SQL,
Perl and Python as part of the core project?

I don't know about Perl, but the PL/Python language is somewhat
neglected as well (though has been slightly improving recently). It's
there because it was already merged ages ago. By today's quality
standards, I believe it would not be accepted into PostgreSQL core.

Regards,
Marti

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Sun, Sep 14, 2014 at 10:22 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

Hi,

Out of curiosity, why is Postgresql's Java support so poor? I am
specifically looking for the ability to write triggers in Java.

Because it hasn't been a priority of contributors. This is how
non-single-vendor open source projects work: people decide what is
important to them and do the work required. If something gets neglected
then I guess it wasn't really important.

I took a look at the PL/Java project and it looked both incomplete and
dead,
yet other languages like Javascript are taking off. I would have expected
to
see very strong support for Java because it's the most frequently used
language on the server-side.

I think Javascript is taking off because JSON is taking off. The problem
with Java is that while there are plenty of use cases for it in the db, it
isn't something which there are *common* use cases for.

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?

On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
cowwoc <cowwoc@bbs.darktech.org> wrote:

Out of curiosity, why is Postgresql's Java support so poor?

To trampoline off what others have said: it gets implemented and maintained if
people want/need it.

But I feel like I have a little more insight into _why_ people aren't taking
the effort, based on experience at my last job.

We were interested in both pl/Java and pl/PHP. In theory, both of those would
allow us to leverage both existing codebases and existing developer skills. We
were looking at taking an active role in maintainership of these two languages
to facilitate our use.

In practice, the amount of code in existing code bases that would be reused for
stored procedures turned out to be very low. Additionally, the number of
developers who had difficulty adapting to plPGSQL programming was 0. As a
result, we found that, in practice, the existing pl/SQL and plPGSQL were
_good_enough_ and there was so little benefit from using other languages that
we couldn't justify the effort of ensuring they worked consistently.

From a meta standpoint, it feels like pl/Java and others are really neat ideas
that simply aren't _necessary_ (although they're nice to have). When it comes
down to work done for employer, it was just less effort to succeed by going the
route of using the existing plSQL/plPGSQL, and employers are all about less
money spent to accomplish the goal.

Other people may have other opinions or stories or whatever. That's mine.

--
Bill Moran
I need your help to succeed:
http://gamesbybill.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 9/15/14, Chris Travers <chris.travers@gmail.com> wrote:

On Sun, Sep 14, 2014 at 10:22 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

Out of curiosity, why is Postgresql's Java support so poor? I am
specifically looking for the ability to write triggers in Java.

Because it hasn't been a priority of contributors. This is how
non-single-vendor open source projects work: people decide what is
important to them and do the work required. If something gets neglected
then I guess it wasn't really important.

What's going on? Why isn't this a core language supported alongside SQL,
Perl and Python as part of the core project?

I have a few questions on this, the answers of which may help answer your
question:

1. How well does having a server-side JVM work, resource-wise, when you
have a forked process model like PostgreSQL? Does having the additional
JVM's pose performance and competition for resources that lighter languages
would not?

So eliminate JVM startup overhead by running (one or more
instances of) JVM as a daemon, using nailgun :
http://en.wikipedia.org/wiki/Java_performance#Startup_time
http://martiansoftware.com/nailgun/

For low overhead (trigger) scripts, JVM startup overhead means
order of magnitude(s) slow down - so nailgun means a massive
speedup.

Nailgun does not have multi-user security separation. Although
if this is for a corporate project, adding such security with "Unix
domain sockets" ought be very straightforward (cite is only a private
email discussion I had with nailgun's author some years ago, where
we concluded this should not be difficult to implement per se).

2. What is your specific use case for a trigger in Java?

Excellent question.

Good luck,
Zenaan

--
Banned for life from Debian, for suggesting Debian's CoC (Code
of Conduct) is being swung in our faces a little too vigorously.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 15/09/2014 08:22, cowwoc wrote:

Hi,

Out of curiosity, why is Postgresql's Java support so poor? I am
specifically looking for the ability to write triggers in Java.

I took a look at the PL/Java project and it looked both incomplete and dead,
yet other languages like Javascript are taking off. I would have expected to
see very strong support for Java because it's the most frequently used
language on the server-side.

This is far from dead. I works perfectly with java 1.7 and postgresql 9.3 ,
but you need maybe a little bit more extra homework + some skills with
maven.
If i managed to build this on a FreeBSD machine, in linux it should a piece of cake.
The docs suck, granted, but the community is very much alive and helpful.
We use it for production environment. We had some really complex Java code, that
we were unwilling to port to pl/pgsql, therefore we gave pl/java a try.
It was worth it. + it has proven to be really stable. No JVM crashes after 2 years in production.

What's going on? Why isn't this a core language supported alongside SQL,
Perl and Python as part of the core project?

Thanks,
Gili

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

--
Achilleas Mantzios
Head of IT DEV
IT DEPT
Dynacom Tankers Mgmt

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 15/09/14 13:30, Achilleas Mantzios wrote:

This is far from dead. I works perfectly with java 1.7 and postgresql
9.3 ,
but you need maybe a little bit more extra homework + some skills with
maven.
If i managed to build this on a FreeBSD machine, in linux it should a
piece of cake.
The docs suck, granted, but the community is very much alive and helpful.
We use it for production environment. We had some really complex Java
code, that
we were unwilling to port to pl/pgsql, therefore we gave pl/java a try.
It was worth it. + it has proven to be really stable. No JVM crashes
after 2 years in production.

+1 for that; we are too.

--
Tim Clarke

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Mon, Sep 15, 2014 at 6:03 AM, Chris Travers <chris.travers@gmail.com> wrote:

On Sun, Sep 14, 2014 at 10:22 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

Hi,

Out of curiosity, why is Postgresql's Java support so poor? I am
specifically looking for the ability to write triggers in Java.

Because it hasn't been a priority of contributors. This is how
non-single-vendor open source projects work: people decide what is important
to them and do the work required. If something gets neglected then I guess
it wasn't really important.

I took a look at the PL/Java project and it looked both incomplete and
dead,
yet other languages like Javascript are taking off. I would have expected
to
see very strong support for Java because it's the most frequently used
language on the server-side.

I think Javascript is taking off because JSON is taking off. The problem
with Java is that while there are plenty of use cases for it in the db, it
isn't something which there are *common* use cases for.

JSON is part of it but there's more. javascript is a language
designed for embedding and so makes very little assumptions about the
host environment. It doesn't use threads which is particularly nice
and that (along with the highly asynchronous nature of the language)
has influenced developer culture and library design. It doesn't
expose things which are dubious to do in a stored procedure and the pl
wrapper can expose such things in a proper API or not at all. Java
OTOH exposes (being a systems language) anything and everything. The
architecture of having the GC embedded inside a postgres process is
awkward to say the least. Don't get me wrong: pl/java works
beautifully if you know what you're doing but you have to approach
things as a minimalist from the java point of view if you want things
to work well and minimalism is not, uh, endemic to the java culture.

There's more: plv8 relies in BSD licensed c++ runtime from google.
It's pretty self contained and friendly. Java is provided by Oracle
('nuff said) with a complicated license that I don't understand TBH.
This doesn't necessarily argue against 'core support' but it's
something to think about.

So I'd argue plv8 has a much better case of being put 'in core', but
I'd argue that neither of them should be. Why? The core team is
already supporting enough code and it seems better to make the
extension framework more robust so that users have a easier route to
pulling in 3rd party libraries than they currently do.

merlin

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Mon, Sep 15, 2014 at 11:23 PM, Merlin Moncure <mmoncure@gmail.com> wrote:

So I'd argue plv8 has a much better case of being put 'in core', but
I'd argue that neither of them should be. Why? The core team is
already supporting enough code and it seems better to make the
extension framework more robust so that users have a easier route to
pulling in 3rd party libraries than they currently do.

It is worth noting that v8 newer than versions 3.14 (if I recall
correctly) has introduced many API breakages making plv8 incompatible
in those cases with newer versions, making it rather harder to
integrate into core with a long-term vision:
https://apps.fedoraproject.org/packages/v8
Regards,
--
Michael

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Tue, Sep 16, 2014 at 1:43 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

https://apps.fedoraproject.org/packages/v8

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Hi guys,

Any chance you guys could help cleaning up the build/deploy process?

This is a pretty big hurdle to overcome for new users.

Gili

On 15/09/2014 8:55 AM, Tim Clarke [via PostgreSQL] wrote:

On 15/09/14 13:30, Achilleas Mantzios wrote:

This is far from dead. I works perfectly with java 1.7 and postgresql
9.3 ,
but you need maybe a little bit more extra homework + some skills with
maven.
If i managed to build this on a FreeBSD machine, in linux it should a
piece of cake.
The docs suck, granted, but the community is very much alive and

helpful.

We use it for production environment. We had some really complex Java
code, that
we were unwilling to port to pl/pgsql, therefore we gave pl/java a try.
It was worth it. + it has proven to be really stable. No JVM crashes
after 2 years in production.

+1 for that; we are too.

--
Tim Clarke

--
Sent via pgsql-general mailing list ([hidden email]
</user/SendEmail.jtp?type=node&node=5819054&i=0>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

------------------------------------------------------------------------
If you reply to this email, your message will be added to the
discussion below:
http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819054.html

To unsubscribe from Why isn't Java support part of Postgresql core?,
click here
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&amp;node=5819025&amp;code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTgxOTAyNXwxNTc0MzIxMjQ3&gt;.
NAML
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&amp;id=instant_html%21nabble%3Aemail.naml&amp;base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&amp;breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml&gt;

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

On 15/09/2014 7:03 AM, Chris Travers wrote:

I have a few questions on this, the answers of which may help answer
your question:

1. How well does having a server-side JVM work, resource-wise, when
you have a forked process model like PostgreSQL? Does having the
additional JVM's pose performance and competition for resources that
lighter languages would not?

I don't think this is really a concern when connection pooling is used
(otherwise you end up creating a new JVM per connection which is indeed
problematic).

2. What is your specific use case for a trigger in Java?

The main drivers are:

1. Not having to learn yet another language. I find the expressiveness
and readability of the other scripting languages very clunky
compared to Java.
2. Ease of porting triggers across databases. The only thing that
really changes across databases is how triggers interact with
input/output parameters. The main body remains the same (thanks to
JDBC). This is quasi portability in the sense that the underlying
SQL is itself quasi portable, but I find it a much more compelling
approach than having to rewrite the triggers for each database type.

Gili

On 15/09/2014 7:58 AM, Bill Moran wrote:

On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
cowwoc <cowwoc@bbs.darktech.org> wrote:

Out of curiosity, why is Postgresql's Java support so poor?

To trampoline off what others have said: it gets implemented and maintained if
people want/need it.

But I feel like I have a little more insight into _why_ people aren't taking
the effort, based on experience at my last job.

We were interested in both pl/Java and pl/PHP. In theory, both of those would
allow us to leverage both existing codebases and existing developer skills. We
were looking at taking an active role in maintainership of these two languages
to facilitate our use.

In practice, the amount of code in existing code bases that would be reused for
stored procedures turned out to be very low. Additionally, the number of
developers who had difficulty adapting to plPGSQL programming was 0. As a
result, we found that, in practice, the existing pl/SQL and plPGSQL were
_good_enough_ and there was so little benefit from using other languages that
we couldn't justify the effort of ensuring they worked consistently.

From a meta standpoint, it feels like pl/Java and others are really neat ideas
that simply aren't _necessary_ (although they're nice to have). When it comes
down to work done for employer, it was just less effort to succeed by going the
route of using the existing plSQL/plPGSQL, and employers are all about less
money spent to accomplish the goal.

Other people may have other opinions or stories or whatever. That's mine.

I'm very glad you posted this because I was thinking the same but needed
someone to reinforce my views. pl/pgsql is beginning to look like the
lesser evil to getting pl/java to work. Sad but true.

I strongly believe that pl/java would catapult the expressiveness of
triggers to a new level, but getting this off the ground will require
the concerted effort of 2-3 dedicated developers.

Gili

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

2014-09-15 19:34 GMT+02:00 cowwoc <cowwoc@bbs.darktech.org>:

On 15/09/2014 7:03 AM, Chris Travers wrote:

I have a few questions on this, the answers of which may help answer your
question:

1. How well does having a server-side JVM work, resource-wise, when you
have a forked process model like PostgreSQL? Does having the additional
JVM's pose performance and competition for resources that lighter languages
would not?

I don't think this is really a concern when connection pooling is used
(otherwise you end up creating a new JVM per connection which is indeed
problematic).

2. What is your specific use case for a trigger in Java?

The main drivers are:

1. Not having to learn yet another language. I find the expressiveness
and readability of the other scripting languages very clunky compared to
Java.

PLpgSQL is different, it is based on Ada language

1. Ease of porting triggers across databases. The only thing that
really changes across databases is how triggers interact with input/output
parameters. The main body remains the same (thanks to JDBC). This is quasi
portability in the sense that the underlying SQL is itself quasi portable,
but I find it a much more compelling approach than having to rewrite the
triggers for each database type.

any time plpgsql will be faster then Java probably due a type

compatibility with Postgres and execution as inprocess

There is a few task, that can be done in database, that will be faster in
PL/Java than PL/pgSQL

Regards

Pavel

2014-09-15 19:37 GMT+02:00 cowwoc <cowwoc@bbs.darktech.org>:

On 15/09/2014 7:58 AM, Bill Moran wrote:

On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
cowwoc <cowwoc@bbs.darktech.org> wrote:

Out of curiosity, why is Postgresql's Java support so poor?

To trampoline off what others have said: it gets implemented and
maintained if
people want/need it.

But I feel like I have a little more insight into _why_ people aren't
taking
the effort, based on experience at my last job.

We were interested in both pl/Java and pl/PHP. In theory, both of those
would
allow us to leverage both existing codebases and existing developer
skills. We
were looking at taking an active role in maintainership of these two
languages
to facilitate our use.

In practice, the amount of code in existing code bases that would be
reused for
stored procedures turned out to be very low. Additionally, the number of
developers who had difficulty adapting to plPGSQL programming was 0. As a
result, we found that, in practice, the existing pl/SQL and plPGSQL were
_good_enough_ and there was so little benefit from using other languages
that
we couldn't justify the effort of ensuring they worked consistently.

From a meta standpoint, it feels like pl/Java and others are really neat
ideas
that simply aren't _necessary_ (although they're nice to have). When it
comes
down to work done for employer, it was just less effort to succeed by
going the
route of using the existing plSQL/plPGSQL, and employers are all about
less
money spent to accomplish the goal.

Other people may have other opinions or stories or whatever. That's mine.

I'm very glad you posted this because I was thinking the same but needed
someone to reinforce my views. pl/pgsql is beginning to look like the
lesser evil to getting pl/java to work. Sad but true.

I strongly believe that pl/java would catapult the expressiveness of
triggers to a new level, but getting this off the ground will require the
concerted effort of 2-3 dedicated developers.

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

2014-09-15 19:46 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:

2014-09-15 19:37 GMT+02:00 cowwoc <cowwoc@bbs.darktech.org>:

On 15/09/2014 7:58 AM, Bill Moran wrote:

On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
cowwoc <cowwoc@bbs.darktech.org> wrote:

Out of curiosity, why is Postgresql's Java support so poor?

To trampoline off what others have said: it gets implemented and
maintained if
people want/need it.

But I feel like I have a little more insight into _why_ people aren't
taking
the effort, based on experience at my last job.

We were interested in both pl/Java and pl/PHP. In theory, both of those
would
allow us to leverage both existing codebases and existing developer
skills. We
were looking at taking an active role in maintainership of these two
languages
to facilitate our use.

In practice, the amount of code in existing code bases that would be
reused for
stored procedures turned out to be very low. Additionally, the number of
developers who had difficulty adapting to plPGSQL programming was 0. As
a
result, we found that, in practice, the existing pl/SQL and plPGSQL were
_good_enough_ and there was so little benefit from using other languages
that
we couldn't justify the effort of ensuring they worked consistently.

From a meta standpoint, it feels like pl/Java and others are really
neat ideas
that simply aren't _necessary_ (although they're nice to have). When it
comes
down to work done for employer, it was just less effort to succeed by
going the
route of using the existing plSQL/plPGSQL, and employers are all about
less
money spent to accomplish the goal.

Other people may have other opinions or stories or whatever. That's
mine.

I'm very glad you posted this because I was thinking the same but needed
someone to reinforce my views. pl/pgsql is beginning to look like the
lesser evil to getting pl/java to work. Sad but true.

I strongly believe that pl/java would catapult the expressiveness of
triggers to a new level, but getting this off the ground will require the
concerted effort of 2-3 dedicated developers.

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

Hi Pavel,

On 15/09/2014 1:40 PM, Pavel Stehule wrote:

The main drivers are:

1. Not having to learn yet another language. I find the
expressiveness and readability of the other scripting
languages very clunky compared to Java.

PLpgSQL is different, it is based on Ada language

I'm sure it's a very lovely language, but it is yet another language
most people are not familiar with and will have to learn.

1. Ease of porting triggers across databases. The only thing that
really changes across databases is how triggers interact with
input/output parameters. The main body remains the same
(thanks to JDBC). This is quasi portability in the sense that
the underlying SQL is itself quasi portable, but I find it a
much more compelling approach than having to rewrite the
triggers for each database type.

any time plpgsql will be faster then Java probably due a type
compatibility with Postgres and execution as inprocess

There is a few task, that can be done in database, that will be faster
in PL/Java than PL/pgSQL

I think developers choosing this route (myself included) are willing to
pay the price in exchange for improved readability/maintainability (the
assumption being that the resulting performance will be "good enough").
There seem to be plenty of people heading in this direction otherwise
other languages (like pl/v8) wouldn't enjoy the popularity they do.

Gili

On 15/09/2014 1:51 PM, Pavel Stehule [via PostgreSQL] wrote:

and I am not sure if Java as stored procedures is living technology,
It was designed as "esperanto", but it is supported only by Oracle
after 14 years.

Pavel

H2, HSQLDB, Derby all support Java triggers. Granted, we are not talking
about MySQL or Oracle here, but these did not add Java triggers as an
afterthought.

Gili

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819098.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

On 09/15/2014 11:49 AM, cowwoc wrote:

Hi Pavel,

On 15/09/2014 1:40 PM, Pavel Stehule wrote:

The main drivers are:

1. Not having to learn yet another language. I find the
expressiveness and readability of the other scripting
languages very clunky compared to Java.

PLpgSQL is different, it is based on Ada language

I'm sure it's a very lovely language, but it is yet another language
most people are not familiar with and will have to learn.

1. Ease of porting triggers across databases. The only thing
that really changes across databases is how triggers interact
with input/output parameters. The main body remains the same
(thanks to JDBC). This is quasi portability in the sense that
the underlying SQL is itself quasi portable, but I find it a
much more compelling approach than having to rewrite the
triggers for each database type.

any time plpgsql will be faster then Java probably due a type
compatibility with Postgres and execution as inprocess

There is a few task, that can be done in database, that will be
faster in PL/Java than PL/pgSQL

I think developers choosing this route (myself included) are willing
to pay the price in exchange for improved readability/maintainability
(the assumption being that the resulting performance will be "good
enough"). There seem to be plenty of people heading in this direction
otherwise other languages (like pl/v8) wouldn't enjoy the popularity
they do.

Gili

I've seen too many good java developers write too much terrible
database-oriented code. If they are good with db and sql, plpgsql will
not be a problem to learn.

2014-09-15 19:49 GMT+02:00 cowwoc <cowwoc@bbs.darktech.org>:

Hi Pavel,

On 15/09/2014 1:40 PM, Pavel Stehule wrote:

The main drivers are:

1. Not having to learn yet another language. I find the
expressiveness and readability of the other scripting languages very clunky
compared to Java.

PLpgSQL is different, it is based on Ada language

I'm sure it's a very lovely language, but it is yet another language most
people are not familiar with and will have to learn.

you need one day learning only .. it contains only necessary functionality
for stored procedures, nothing more.

It is like Java in 90 years - just simple

1. Ease of porting triggers across databases. The only thing that
really changes across databases is how triggers interact with input/output
parameters. The main body remains the same (thanks to JDBC). This is quasi
portability in the sense that the underlying SQL is itself quasi portable,
but I find it a much more compelling approach than having to rewrite the
triggers for each database type.

any time plpgsql will be faster then Java probably due a type

compatibility with Postgres and execution as inprocess

There is a few task, that can be done in database, that will be faster
in PL/Java than PL/pgSQL

I think developers choosing this route (myself included) are willing to
pay the price in exchange for improved readability/maintainability (the
assumption being that the resulting performance will be "good enough").
There seem to be plenty of people heading in this direction otherwise other
languages (like pl/v8) wouldn't enjoy the popularity they do.

I know a situation in Czech Republic well and in Europe little bit

My estimation is about PostgreSQL applications

95% applications is wrote without stored procedures
4% applications is wrote with PL/pgSQL
.9% is combination PL/pgSQL with PL/Perl or PL/Python (Perl is older with
CPAN, Python is popular in GIS community)
0.01% has all other .. pl/v8 was used mainly for JSON manipulation, because
this possibility was not in PG, PL/R, PL/Lua, PL/PHP, PL/v8 has very small
user community

For typical Java or Javascript users the stored procedures are devil still.