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

Why isn't Java support part of Postgresql core?

From
cowwoc
Date:
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.


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

From
Marti Raudsepp
Date:
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


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

From
Chris Travers
Date:


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?

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

From
Bill Moran
Date:
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


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

From
Zenaan Harkness
Date:
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.


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

From
Achilleas Mantzios
Date:
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



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

From
Tim Clarke
Date:
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



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

From
Merlin Moncure
Date:
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


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

From
Michael Paquier
Date:
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


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

From
Michael Paquier
Date:
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


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

From
cowwoc
Date:
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])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



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



View this message in context: Re: Why isn't Java support part of Postgresql core?
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

From
cowwoc
Date:
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

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

From
cowwoc
Date:
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


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

From
Pavel Stehule
Date:


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
 

    Gili


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

    From
    Pavel Stehule
    Date:


    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
     

    Gili


    --
    Sent via pgsql-general mailing list (pgsql-general@postgresql.org)

    To make changes to your subscription:
    http://www.postgresql.org/mailpref/pgsql-general

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

    From
    cowwoc
    Date:
    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

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

    From
    Pavel Stehule
    Date:


    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
     

    Regards

    Pavel
     

    Gili


    --
    Sent via pgsql-general mailing list (pgsql-general@postgresql.org)

    To make changes to your subscription:
    http://www.postgresql.org/mailpref/pgsql-general


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

    From
    cowwoc
    Date:
    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: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    Rob Sargent
    Date:
    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.

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

    From
    Pavel Stehule
    Date:


    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.



     

    Gili

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

    From
    cowwoc
    Date:
    On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
    On 09/15/2014 11:49 AM, cowwoc wrote:
    I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be "good enough"). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do.

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

    lup,

    Then does Postgresql support languages other than pl/pgsql? I'm not trying to tear down pl/pgsql, simply pointing out that there is strong demand for other languages as well.

    And to answer Pavel's earlier point: the lack of developers getting behind pl/java and JDBC driver does not equate the lack of demand for those tools. For every one person contributing patches, there are 1000s who do not but are more than happy to use the finished work.

    Gili


    View this message in context: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    cowwoc
    Date:
    On 15/09/2014 2:12 PM, cowwoc wrote:
    On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
    On 09/15/2014 11:49 AM, cowwoc wrote:
    I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be "good enough"). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do.

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

    lup,

    Then does Postgresql support languages other than pl/pgsql? I'm not trying to tear down pl/pgsql, simply pointing out that there is strong demand for other languages as well.

    And to answer Pavel's earlier point: the lack of developers getting behind pl/java and JDBC driver does not equate the lack of demand for those tools. For every one person contributing patches, there are 1000s who do not but are more than happy to use the finished work.

    Gili

    "Then does" was meant to read "Then *why* does" :)

    Gili


    View this message in context: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    Adrian Klaver
    Date:
    On 09/15/2014 11:00 AM, Rob Sargent wrote:
    > On 09/15/2014 11:49 AM, cowwoc wrote:
    >> Hi Pavel,
    >>
    >> On 15/09/2014 1:40 PM, Pavel Stehule wrote:
    >>> The main drivers are:
    >>>
    >>>      1. Not having to learn yet another language. I find the
    >>>         expressiveness and readability of the other scripting
    >>>         languages very clunky compared to Java.
    >>>
    >>>
    >
    >> Gili
    > I've seen too many good java developers write too much terrible
    > database-oriented code.  If they are good with db and sql, plpgsql will
    > not be a problem to learn.
    >
    
    Agreed, plpgsql is SQL with Postgres extensions. I went down this road
    with plpythonu. I am comfortable in Python, so I thought it would be
    easier to write functions using plpythonu. I actually did this
    backwards. I had created a fairly complex function in plpgsql and I
    figured I could simplify by using plpythonu. I was well into it when I
    had realized I written more code in plpythonu than plpgsql and still was
    not close to completing it. I still use plpythonu but only when I need
    the dynamic nature of Python or really need to use some Python module.
    
    --
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    

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

    From
    Szymon Guz
    Date:


    On 15 September 2014 20:13, cowwoc <cowwoc@bbs.darktech.org> wrote:

    On 15/09/2014 2:12 PM, cowwoc wrote:
    On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
    On 09/15/2014 11:49 AM, cowwoc wrote:
    I think developers choosing this route (myself included) are willing to pay the price in exchange for improved readability/maintainability (the assumption being that the resulting performance will be "good enough"). There seem to be plenty of people heading in this direction otherwise other languages (like pl/v8) wouldn't enjoy the popularity they do.

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

    lup,

    Then does Postgresql support languages other than pl/pgsql? I'm not trying to tear down pl/pgsql, simply pointing out that there is strong demand for other languages as well.

    And to answer Pavel's earlier point: the lack of developers getting behind pl/java and JDBC driver does not equate the lack of demand for those tools. For every one person contributing patches, there are 1000s who do not but are more than happy to use the finished work.

    Gili

    "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

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

    From
    Alberto Cabello Sánchez
    Date:
    On Mon, 15 Sep 2014 13:34:53 -0400
    cowwoc <cowwoc@bbs.darktech.org> wrote:
    
    > > 2.  What is your specific use case for a trigger in Java?
    >
    > The main drivers are:
    >
    >  1. Not having to learn yet another language.
    
    Bear in mind that DB programmers often know SQL. To me, and apparently to them,
    PL/pgsql seems closer to the already-known SQL than PL/JAVA.
    
    Besides that, PL/JAVA -which I honestly think is a great concept in itself-
    doesn't free you from learning "yet another language" if you are working with
    PHP, Python, Node.js, etc... In these cases, PL/pgsql is a safer bet.
    
    --
    Alberto Cabello Sánchez
    <alberto@unex.es>
    
    
    

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

    From
    Thomas Kellerer
    Date:
    cowwoc wrote on 15.09.2014 19:55:
    > H2, HSQLDB, Derby all support Java triggers.
    
    But only because they already live/run inside a JVM, so it's the "natural" choice of language.
    
    And H2 and Derby *only* support Java stored procedures.
    
    The main disadvantage I see with that is, that you can't "just" write a procedure (or trigger) with a simple
    (procedural)SQL Statement. Yyou need to compile it, package into a jar file and the add the jar file(s) to the
    classpathof the application (or the server process). 
    
    This essentially means you need to restart your application or the server when you deploy a trigger.
    Hardly anyhting that you want to do in a production environment.
    
    > Granted, we are not talking about MySQL or Oracle here,
    >but these did not add Java triggers as an afterthought.
    
    MySQL does not have Java triggers (or procedures).
    
    
    
    
    
    
    

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

    From
    cowwoc
    Date:
    On 15/09/2014 3:50 PM, Thomas Kellerer [via PostgreSQL] wrote:

    > cowwoc wrote on 15.09.2014 19:55:
    > > H2, HSQLDB, Derby all support Java triggers.
    >
    > But only because they already live/run inside a JVM, so it's the
    > "natural" choice of language.
    >
    > And H2 and Derby *only* support Java stored procedures.
    >
    > The main disadvantage I see with that is, that you can't "just" write
    > a procedure (or trigger) with a simple (procedural) SQL Statement.
    > Yyou need to compile it, package into a jar file and the add the jar
    > file(s) to the 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: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    David G Johnston
    Date:
    cowwoc wrote
    > On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
    >> On 09/15/2014 11:49 AM, cowwoc wrote:
    >>> I think developers choosing this route (myself included) are willing
    >>> to pay the price in exchange for improved readability/maintainability
    >>> (the assumption being that the resulting performance will be "good
    >>> enough"). There seem to be plenty of people heading in this direction
    >>> otherwise other languages (like pl/v8) wouldn't enjoy the popularity
    >>> they do.
    >>>
    >>> Gili
    >> I've seen too many good java developers write too much terrible
    >> database-oriented code.  If they are good with db and sql, plpgsql
    >> will not be a problem to learn.
    >
    > lup,
    >
    > Then does Postgresql support languages other than pl/pgsql? I'm not
    > trying to tear down pl/pgsql, simply pointing out that there is strong
    > demand for other languages as well.
    >
    > And to answer Pavel's earlier point: the lack of developers getting
    > behind pl/java and JDBC driver does not equate the lack of demand for
    > those tools. For every one person contributing patches, there are 1000s
    > who do not but are more than happy to use the finished work.
    >
    > Gili
    
    I'm singing with the choir here but getting some of those thousand bodies
    contributing to both pl/java and existing or "next generation" Jdbc drivers
    would be nice.  And that doesn't just mean code - updated articles and
    buildfarm animals are just a couple of resources that could be contributed.
    If nothing else make the projects look more lively than current even if the
    code itself is unchanged.
    
    If you know SQL and Java then you have enough skill and experience to use
    the proper tool for the job instead of turning everything in a java-nail for
    your java-hammer.
    
    Most everything that can be done in this arena can be done outside of core.
    There may be things a pure java developer would like the core to provide
    that would require C programming skills but likely, as mentioned, those
    support parts would benefit more than only Java and would be embraced by the
    core community.
    
    I'll agree, though without personal experience, that a java trigger is more
    portable than a pl/pgsql one.  At the same time users utilizing PostgreSQL
    to its fullest are going to have significant portability issues since custom
    data types and aggregates, arrays, and other advanced features that are used
    by applications are not all that portable.
    
    I think we'd love to help make it easier for java-only shops to target
    PostgreSQL as their backend but there has to be some payoff to the people
    putting up the resources to make it happen.  That is much more likely to
    occur because someone with a huge installed base of java code wants to use
    PostgreSQL to enhance their product.  In that case adding more core features
    to entice those people to come over seems a better approach than devoting
    resources to adding capabilities that may not be strongly accepted nor fully
    useful because the people writing them are not sufficiently invested in the
    outcome.
    
    David J.
    
    
    
    
    
    
    --
    View this message in context:
    http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819145.html
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.
    
    
    

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

    From
    Szymon Guz
    Date:
    On 16 September 2014 03:07, David G Johnston <david.g.johnston@gmail.com> wrote:
    cowwoc wrote
    > On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
    >> On 09/15/2014 11:49 AM, cowwoc wrote:
    >>> I think developers choosing this route (myself included) are willing
    >>> to pay the price in exchange for improved readability/maintainability
    >>> (the assumption being that the resulting performance will be "good
    >>> enough"). There seem to be plenty of people heading in this direction
    >>> otherwise other languages (like pl/v8) wouldn't enjoy the popularity
    >>> they do.
    >>>
    >>> Gili
    >> I've seen too many good java developers write too much terrible
    >> database-oriented code.  If they are good with db and sql, plpgsql
    >> will not be a problem to learn.
    >
    > lup,
    >
    > Then does Postgresql support languages other than pl/pgsql? I'm not
    > trying to tear down pl/pgsql, simply pointing out that there is strong
    > demand for other languages as well.
    >
    > And to answer Pavel's earlier point: the lack of developers getting
    > behind pl/java and JDBC driver does not equate the lack of demand for
    > those tools. For every one person contributing patches, there are 1000s
    > who do not but are more than happy to use the finished work.
    >
    > Gili

    I'm singing with the choir here but getting some of those thousand bodies
    contributing to both pl/java and existing or "next generation" Jdbc drivers
    would be nice.

    What do you mean by the "next generation"?
     
    - Szymon

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

    From
    Peter Eisentraut
    Date:
    On 9/15/14 1:30 PM, cowwoc wrote:
    > Any chance you guys could help cleaning up the build/deploy process?
    >
    > This is a pretty big hurdle to overcome for new users.
    
    I'm glad to hear that PL/Java is still working well for some people.
    
    Last I saw it was stuck in a transition of the build system from make to
    maven, and the documentation was inconsistent either way.
    
    It looks like with a little non-coding help this could be cleared up.
    
    
    
    

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

    From
    Peter Eisentraut
    Date:
    On 9/15/14 1:46 PM, Pavel Stehule wrote:
    > I am strong sceptic. There is relative slow progress in JDBC driver,
    > that is 100x more important project than PL/Java - so It is hard to
    > believe, so there can be 3 developers, who start work on PL/Java.
    
    Stupid, completely offensive guess:  Most Java programmers work in
    "enterprise" environments and are not allowed to or used to contributing
    to open source?
    
    
    
    

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

    From
    Pavel Stehule
    Date:


    2014-09-17 22:54 GMT+02:00 Peter Eisentraut <peter_e@gmx.net>:
    On 9/15/14 1:46 PM, Pavel Stehule wrote:
    > I am strong sceptic. There is relative slow progress in JDBC driver,
    > that is 100x more important project than PL/Java - so It is hard to
    > believe, so there can be 3 developers, who start work on PL/Java.

    Stupid, completely offensive guess:  Most Java programmers work in
    "enterprise" environments and are not allowed to or used to contributing
    to open source?


    So what can be changed?

    Pavel

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

    From
    cowwoc
    Date:
    On 17/09/2014 5:05 PM, Pavel Stehule wrote:
    2014-09-17 22:54 GMT+02:00 Peter Eisentraut <peter_e@gmx.net>:
    On 9/15/14 1:46 PM, Pavel Stehule wrote:
    > I am strong sceptic. There is relative slow progress in JDBC driver,
    > that is 100x more important project than PL/Java - so It is hard to
    > believe, so there can be 3 developers, who start work on PL/Java.

    Stupid, completely offensive guess:  Most Java programmers work in
    "enterprise" environments and are not allowed to or used to contributing
    to open source?


    So what can be changed?

    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

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

    From
    cowwoc
    Date:
    On 17/09/2014 4:51 PM, Peter Eisentraut wrote:
    > On 9/15/14 1:30 PM, cowwoc wrote:
    >> Any chance you guys could help cleaning up the build/deploy process?
    >>
    >> This is a pretty big hurdle to overcome for new users.
    > I'm glad to hear that PL/Java is still working well for some people.
    >
    > Last I saw it was stuck in a transition of the build system from make to
    > maven, and the documentation was inconsistent either way.
    >
    > It looks like with a little non-coding help this could be cleared up.
    >
    
    Peter,
    
    I think it would be much more productive to fix the deployment problem
    (instead of throwing more documentation at it). If the extension came
    bundled with Postgresql and was as easy to install as "CREATE EXTENSION
    pljava" then we wouldn't be having this discussion.
    
    Asking end-users to compile the project from source sounds like a
    non-starter to me.
    
    Gili
    
    
    

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

    From
    John R Pierce
    Date:
    On 9/17/2014 2:50 PM, cowwoc wrote:
    > I think it would be much more productive to fix the deployment problem
    > (instead of throwing more documentation at it). If the extension came
    > bundled with Postgresql and was as easy to install as "CREATE
    > EXTENSION pljava" then we wouldn't be having this discussion.
    
    I believe a major issue is the JNI interface...   even on a specific
    platform like RHEL6 there can be any of a rather wide range of different
    java's installed, openjdk 1.6, openjdk 1.7, or any of various Sun Java
    SE or EE builds, or even (ARRRGH) GCJ...... the JNI components need to
    be linked to a specific one of these to function properly.
    
    
    --
    john r pierce                                      37N 122W
    somewhere on the middle of the left coast
    
    
    
    

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

    From
    cowwoc
    Date:
    On 17/09/2014 6:04 PM, John R Pierce [via PostgreSQL] wrote:

    > On 9/17/2014 2:50 PM, cowwoc wrote:
    > > I think it would be much more productive to fix the deployment problem
    > > (instead of throwing more documentation at it). If the extension came
    > > bundled with Postgresql and was as easy to install as "CREATE
    > > EXTENSION pljava" then we wouldn't be having this discussion.
    >
    > I believe a major issue is the JNI interface...   even on a specific
    > platform like RHEL6 there can be any of a rather wide range of different
    > java's installed, openjdk 1.6, openjdk 1.7, or any of various Sun Java
    > SE or EE builds, or even (ARRRGH) GCJ...... the JNI components need to
    > be linked to a specific one of these to function properly.

    Hi John,

    Can you be more specific? Are you talking about load-time linking
    against jvm.dll/so?

    Gili


    View this message in context: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    John R Pierce
    Date:
    On 9/17/2014 3:07 PM, cowwoc wrote:
    >
    > Can you be more specific? Are you talking about load-time linking
    > against jvm.dll/so?
    
    $JAVA_HOME/jre/lib/amd64/server/libjvm.so  or whatever, yeah.    the
    path of that relative to $JAVA_HOME is rather variable, depending on a
    lot of things, like 32 vs 64 bit JRE, x86 vs sparc/solaris vs AIX/power,
    and I think GCJ has a considerably different directory layout.
    
    Also...   are the jni.h files the same or at least interchangable for
    the various flavors of Java?
    
    
    
    
    
    
    
    
    --
    john r pierce                                      37N 122W
    somewhere on the middle of the left coast
    
    
    
    

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

    From
    cowwoc
    Date:
    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

    On 17/09/2014 6:26 PM, John R Pierce [via PostgreSQL] wrote:
    On 9/17/2014 3:07 PM, cowwoc wrote:
    >
    > Can you be more specific? Are you talking about load-time linking
    > against jvm.dll/so?

    $JAVA_HOME/jre/lib/amd64/server/libjvm.so  or whatever, yeah.    the
    path of that relative to $JAVA_HOME is rather variable, depending on a
    lot of things, like 32 vs 64 bit JRE, x86 vs sparc/solaris vs AIX/power,
    and I think GCJ has a considerably different directory layout.

    Also...   are the jni.h files the same or at least interchangable for
    the various flavors of Java?








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



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



    If you reply to this email, your message will be added to the discussion below:
    http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819414.html
    To unsubscribe from Why isn't Java support part of Postgresql core?, click here.
    NAML



    View this message in context: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    John R Pierce
    Date:
    On 9/17/2014 5:02 PM, cowwoc wrote:
    > As far as I understand it, this is the end-user's problem (to be
    > documented) as opposed to a development problem. As far as I know, the
    > jni.h files should be compatible with all other JDKs on the same
    > platforms so you only need to release one DLL/SO per platforms (like
    > you would if this was plain C) and it is then up to the user to make
    > sure the Postgres process has the right JRE DLL/SO in its PATH.
    >
    > This shouldn't be too technically difficult to pull off.
    
    right.
    
      wait, which user?    the java user/developer who typically hasn't a
    clue how system-level stuff functions or operates, or the postgresql
    database administrator, who probably hasn't a clue how java works
    internally ?
    
    
    
    --
    john r pierce                                      37N 122W
    somewhere on the middle of the left coast
    
    
    
    

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

    From
    Tom Lane
    Date:
    John R Pierce <pierce@hogranch.com> writes:
    > On 9/17/2014 5:02 PM, cowwoc wrote:
    >> This shouldn't be too technically difficult to pull off.
    
    > right.
    
    >   wait, which user?    the java user/developer who typically hasn't a
    > clue how system-level stuff functions or operates, or the postgresql
    > database administrator, who probably hasn't a clue how java works
    > internally ?
    
    There are a number of reasons why this (pl/java in core) isn't likely
    to happen; one being that I think a good fraction of the core PG
    developers fall into the "haven't a clue how java works internally"
    camp.  But here's the *key* reason: if pl/java is failing to stay afloat
    as an external project, that is a terrible reason for pulling it into
    core.  It suggests strongly that the manpower or interest to keep it
    going simply doesn't exist.  Making it part of the core distribution
    would not fix that, and moreover it would demand attention from PG core
    developers who are not particularly motivated or capable to do anything
    with it.
    
    If you feel that pl/java isn't sufficiently well maintained, the
    short answer is that you should get involved with it as it is.
    In the end, open source is all about "scratch your own itch".
    
                regards, tom lane
    
    
    

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

    From
    cowwoc
    Date:
    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

    On 18/09/2014 12:31 AM, Tom Lane-2 [via PostgreSQL] wrote:
    John R Pierce <[hidden email]> writes:
    > On 9/17/2014 5:02 PM, cowwoc wrote:
    >> This shouldn't be too technically difficult to pull off.

    > right.

    >   wait, which user?    the java user/developer who typically hasn't a
    > clue how system-level stuff functions or operates, or the postgresql
    > database administrator, who probably hasn't a clue how java works
    > internally ?

    There are a number of reasons why this (pl/java in core) isn't likely
    to happen; one being that I think a good fraction of the core PG
    developers fall into the "haven't a clue how java works internally"
    camp.  But here's the *key* reason: if pl/java is failing to stay afloat
    as an external project, that is a terrible reason for pulling it into
    core.  It suggests strongly that the manpower or interest to keep it
    going simply doesn't exist.  Making it part of the core distribution
    would not fix that, and moreover it would demand attention from PG core
    developers who are not particularly motivated or capable to do anything
    with it.

    If you feel that pl/java isn't sufficiently well maintained, the
    short answer is that you should get involved with it as it is.
    In the end, open source is all about "scratch your own itch".

                            regards, tom lane


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



    If you reply to this email, your message will be added to the discussion below:
    http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819443.html
    To unsubscribe from Why isn't Java support part of Postgresql core?, click here.
    NAML



    View this message in context: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    Chris Travers
    Date:


    On Wed, Sep 17, 2014 at 9:42 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
    Tom,

    For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do.

    The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path).

    But what the core team has done is provide a pretty stable interface for getting to that point.  The extension interface is well documented and quite stable IME.  If the pl/java project can't get it to a point where you can make && make install, then I don't see what would possibly benefit from getting into core.

    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.

    Gili

    On 18/09/2014 12:31 AM, Tom Lane-2 [via PostgreSQL] wrote:
    John R Pierce <[hidden email]> writes:
    > On 9/17/2014 5:02 PM, cowwoc wrote:
    >> This shouldn't be too technically difficult to pull off.

    > right.

    >   wait, which user?    the java user/developer who typically hasn't a
    > clue how system-level stuff functions or operates, or the postgresql
    > database administrator, who probably hasn't a clue how java works
    > internally ?

    There are a number of reasons why this (pl/java in core) isn't likely
    to happen; one being that I think a good fraction of the core PG
    developers fall into the "haven't a clue how java works internally"
    camp.  But here's the *key* reason: if pl/java is failing to stay afloat
    as an external project, that is a terrible reason for pulling it into
    core.  It suggests strongly that the manpower or interest to keep it
    going simply doesn't exist.  Making it part of the core distribution
    would not fix that, and moreover it would demand attention from PG core
    developers who are not particularly motivated or capable to do anything
    with it.

    If you feel that pl/java isn't sufficiently well maintained, the
    short answer is that you should get involved with it as it is.
    In the end, open source is all about "scratch your own itch".

                            regards, tom lane


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



    If you reply to this email, your message will be added to the discussion below:
    http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819443.html
    To unsubscribe from Why isn't Java support part of Postgresql core?, click here.
    NAML



    --
    Best Wishes,
    Chris Travers

    Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.

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

    From
    cowwoc
    Date:
    Chris,

    On 18/09/2014 1:07 AM, Chris Travers wrote:
    On Wed, Sep 17, 2014 at 9:42 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
    Tom,

    For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do.

    The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path).

    But what the core team has done is provide a pretty stable interface for getting to that point.  The extension interface is well documented and quite stable IME.  If the pl/java project can't get it to a point where you can make && make install, then I don't see what would possibly benefit from getting into core.

    Bare with me for a moment while I walk you through the Windows (for dummies) experience I had in mind.

    If you take a look at the Windows installation, it ships with lib/hstore.dll which enables users to invoke "make extension hstore" (no need to build anything). I'm talking about doing the same thing for pljava. I suggest adding an optional feature in the Windows installer (I believe it's called Application Stack Builder) for pljava. When enabled, it would unpack lib/pljava.dll and a private JRE (so users don't have to mess around with library paths). Users can then enable the extension with a simple invocation of "CREATE EXTENSION pljava".

    It doesn't get easier than this. And of course you'd do the equivalent thing for *nix (investigate how it works for hstore and provide an equivalent experience for pljava).

    Gili

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

    From
    Misa Simic
    Date:


    On Thursday, September 18, 2014, cowwoc <cowwoc@bbs.darktech.org> wrote:
    Chris,

    On 18/09/2014 1:07 AM, Chris Travers wrote:
    On Wed, Sep 17, 2014 at 9:42 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
    Tom,

    For starters, let's talk strictly about improving the deployment situation, which the core team *is* uniquely positioned to do.

    The pl/java author(s) should figure out what needs to be done but once that's known we need to do *something* in core so the deployment process is reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to Postgresql's library path).

    But what the core team has done is provide a pretty stable interface for getting to that point.  The extension interface is well documented and quite stable IME.  If the pl/java project can't get it to a point where you can make && make install, then I don't see what would possibly benefit from getting into core.

    Bare with me for a moment while I walk you through the Windows (for dummies) experience I had in mind.

    If you take a look at the Windows installation, it ships with lib/hstore.dll which enables users to invoke "make extension hstore" (no need to build anything). I'm talking about doing the same thing for pljava. I suggest adding an optional feature in the Windows installer (I believe it's called Application Stack Builder) for pljava. When enabled, it would unpack lib/pljava.dll and a private JRE (so users don't have to mess around with library paths). Users can then enable the extension with a simple invocation of "CREATE EXTENSION pljava".

    It doesn't get easier than this. And of course you'd do the equivalent thing for *nix (investigate how it works for hstore and provide an equivalent experience for pljava).

    Gili

    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

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

    From
    David G Johnston
    Date:
    cowwoc wrote
    > Chris,
    >
    > On 18/09/2014 1:07 AM, Chris Travers wrote:
    >> On Wed, Sep 17, 2014 at 9:42 PM, cowwoc <
    
    > cowwoc@.darktech
    
    >
    > > <mailto:
    
    > cowwoc@.darktech
    
    > >> wrote:
    >>
    >>     Tom,
    >>
    >>     For starters, let's talk strictly about improving the deployment
    >>     situation, which the core team *is* uniquely positioned to do.
    >>
    >>     The pl/java author(s) should figure out what needs to be done but
    >>     once that's known we need to do *something* in core so the
    >>     deployment process is reduced to 1-2 steps max (CREATE EXTENSION
    >>     pljava, and add Java to Postgresql's library path).
    >>
    >>
    >> But what the core team has done is provide a pretty stable interface
    >> for getting to that point.  The extension interface is well documented
    >> and quite stable IME.  If the pl/java project can't get it to a point
    >> where you can make && make install, then I don't see what would
    >> possibly benefit from getting into core.
    >
    > Bare with me for a moment while I walk you through the Windows (for
    > dummies) experience I had in mind.
    >
    > If you take a look at the Windows installation, it ships with
    > lib/hstore.dll which enables users to invoke "make extension hstore" (no
    > need to build anything). I'm talking about doing the same thing for
    > pljava. I suggest adding an optional feature in the Windows installer (I
    > believe it's called Application Stack Builder) for pljava. When enabled,
    > it would unpack lib/pljava.dll and a private JRE (so users don't have to
    > mess around with library paths). Users can then enable the extension
    > with a simple invocation of "CREATE EXTENSION pljava".
    
    What distributions of JRE are available on the Windows platform and which
    ones are allowed to be "privately distributed"?
    
    For this scenario your target audience is the people, at EnterpriseDB, who
    package the Windows installer.  IIRC PostGIS is part of the builder - and it
    is definitely not core maintained - so pl/java should be no different.
    
    Each platform is different and the package builders should deal with making
    pl/java easy deploy - but the project itself needs to help facilitate that
    end (through code and documentation).  Regardless, the core team, for
    reasons already stated, likely will not and should not be the maintainers of
    pl/java.  It needs to be an extension and interface with PostgreSQL via the
    provided mechanisms.
    
    David J.
    
    
    
    
    --
    View this message in context:
    http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819489.html
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.
    
    
    

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

    From
    John R Pierce
    Date:
    On 9/18/2014 6:18 AM, David G Johnston wrote:
    > What distributions of JRE are available on the Windows platform and which
    > ones are allowed to be "privately distributed"?
    
    afaik, Sun/Oracle is /the/ Java for Windows, and AFAIK, it does NOT
    allow redistribution, Oracle wants you to register each usage.
    
    also as far as I know, java on 64bit windows defaults to only installing
    a 32 bit java, since thats what most browsers use.
    
    hmmm, for extra fun, the JRE 7 I have on my win8 box here, I'm not even
    SEEING the server/jni libraries?!?
    
    
    --
    john r pierce                                      37N 122W
    somewhere on the middle of the left coast
    
    
    
    

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

    From
    Szymon Guz
    Date:


    On 18 September 2014 17:32, John R Pierce <pierce@hogranch.com> wrote:
    On 9/18/2014 6:18 AM, David G Johnston wrote:
    What distributions of JRE are available on the Windows platform and which
    ones are allowed to be "privately distributed"?

    afaik, Sun/Oracle is /the/ Java for Windows, and AFAIK, it does NOT allow redistribution, Oracle wants you to register each usage.

    also as far as I know, java on 64bit windows defaults to only installing a 32 bit java, since thats what most browsers use.

    hmmm, for extra fun, the JRE 7 I have on my win8 box here, I'm not even SEEING the server/jni libraries?!?

    Are we distributing perl and python with postgres as well?

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

    From
    cowwoc
    Date:
    On 18/09/2014 9:18 AM, David G Johnston [via PostgreSQL] wrote:
    > 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)

    > 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: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    cowwoc
    Date:
    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

    On 18/09/2014 11:33 AM, John R Pierce [via PostgreSQL] wrote:
    On 9/18/2014 6:18 AM, David G Johnston wrote:
    > What distributions of JRE are available on the Windows platform and which
    > ones are allowed to be "privately distributed"?

    afaik, Sun/Oracle is /the/ Java for Windows, and AFAIK, it does NOT
    allow redistribution, Oracle wants you to register each usage.

    also as far as I know, java on 64bit windows defaults to only installing
    a 32 bit java, since thats what most browsers use.

    hmmm, for extra fun, the JRE 7 I have on my win8 box here, I'm not even
    SEEING the server/jni libraries?!?


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



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



    If you reply to this email, your message will be added to the discussion below:
    http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819509.html
    To unsubscribe from Why isn't Java support part of Postgresql core?, click here.
    NAML



    View this message in context: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    John R Pierce
    Date:
    On 9/18/2014 9:07 AM, cowwoc wrote:
    > You are confusing a private JRE installation with the public JRE
    > installation (yes, there is such a thing). The public JRE is found in
    > java/jre8. The private JRE is found in java/jdk1.8.0_20/jre.
    >
    > http://www.oracle.com/technetwork/java/javase/jdk-8-readme-2095712.html#redistribution
    > gives you permission to redistribute the JRE directory that ships
    > inside each JDK installation. If you dig into jre/bin/server you will
    > find jvm.dll.
    
    ah, that I see... C:\Program Files\Java\jre7\bin\server\jvm.dll
    
    for some reason I was thinking it needed {lib}jni.{so,dll}
    
    
    
    
    --
    john r pierce                                      37N 122W
    somewhere on the middle of the left coast
    
    
    
    

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

    From
    Szymon Guz
    Date:


    On 18 September 2014 18:54, John R Pierce <pierce@hogranch.com> wrote:
    On 9/18/2014 9:07 AM, cowwoc wrote:
    You are confusing a private JRE installation with the public JRE installation (yes, there is such a thing). The public JRE is found in java/jre8. The private JRE is found in java/jdk1.8.0_20/jre.

    http://www.oracle.com/technetwork/java/javase/jdk-8-readme-2095712.html#redistribution gives you permission to redistribute the JRE directory that ships inside each JDK installation. If you dig into jre/bin/server you will find jvm.dll.

    ah, that I see... C:\Program Files\Java\jre7\bin\server\jvm.dll

    for some reason I was thinking it needed {lib}jni.{so,dll}

     
    Does it mean that there should be distributed many jvm.dlls for each of the jvm versions?

    Szymon

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

    From
    John R Pierce
    Date:
    On 9/18/2014 10:17 AM, Szymon Guz wrote:
    > Does it mean that there should be distributed many jvm.dlls for each
    > of the jvm versions?
    
    jvm.dll is part of the jre, its not a standalone library.
    
    
    
    --
    john r pierce                                      37N 122W
    somewhere on the middle of the left coast
    
    
    
    

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

    From
    cowwoc
    Date:
    On 18/09/2014 1:31 PM, John R Pierce [via PostgreSQL] wrote:
    > On 9/18/2014 10:17 AM, Szymon Guz wrote:
    > > Does it mean that there should be distributed many jvm.dlls for each
    > > of the jvm versions?
    >
    > jvm.dll is part of the jre, its not a standalone library.

    Right, so to recap: each platform will only need one jvm.dll/so library
    (which you would update over time). You don't need to include one
    version for Oracle JDK, OpenJDK, GCJ. You'd pick one, and bundle its
    jvm.dll (I'd suggest going with Oracle's version since it has the best
    stability/performance story). I don't believe there are any licensing
    terms/requirements for private JREs beyond limiting which files you
    redistribute, so from a licensing point of view I think the Postgresql
    team would find it acceptable.

    Gili


    View this message in context: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    John R Pierce
    Date:
    On 9/18/2014 11:06 AM, cowwoc wrote:
    > On 18/09/2014 1:31 PM, John R Pierce [via PostgreSQL] wrote:
    > > On 9/18/2014 10:17 AM, Szymon Guz wrote:
    > > > Does it mean that there should be distributed many jvm.dlls for each
    > > > of the jvm versions?
    > >
    > > jvm.dll is part of the jre, its not a standalone library.
    >
    > Right, so to recap: each platform will only need one jvm.dll/so library
    > (which you would update over time). You don't need to include one
    > version for Oracle JDK, OpenJDK, GCJ. You'd pick one, and bundle its
    > jvm.dll (I'd suggest going with Oracle's version since it has the best
    > stability/performance story). I don't believe there are any licensing
    > terms/requirements for private JREs beyond limiting which files you
    > redistribute, so from a licensing point of view I think the Postgresql
    > team would find it acceptable.
    
    um, I'm pretty sure that dll/so doesn't work without the rest of the JRE
    around it.  I would think the platform packager would need to bundle the
    whole 'private' JRE they chose including that jvm.dll/so, and install
    that somewhere in or around the postgres code tree, along with the
    pljava.so/dll that binds it all together, if the user chooses to install
    pljava support.
    
    
    --
    john r pierce                                      37N 122W
    somewhere on the middle of the left coast
    
    
    
    

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

    From
    cowwoc
    Date:
    On 18/09/2014 2:21 PM, John R Pierce [via PostgreSQL] wrote:

    > > 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: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    John R Pierce
    Date:
    On 9/18/2014 11:44 AM, cowwoc wrote:
    >
    > Yes, that's what I meant. I just wanted to reinforce the fact that you
    > don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick
    > one and bundle it alongside PG and pl/java.
    
    I think a lawyer would have to pick apart the JRE redistribution license
    to confirm that this use case is acceptable...   the catch-22 is that
    pljava is running user java modules, not just the software its being
    distributed with, and I'm not sure the redistribution license allows that.
    
    specifically...
    
    > License  to   Distribute   Software.  Subject to ..., Oracle grants you ... license ... to ... distribute the
    Software..., provided that (i) you distribute the Software ... only bundled as part of, and for the sole purpose of
    running,your Programs, (ii)... 
    
    its that 'sole purpose' part that I wonder about.   FWIW, thats from the JRE 6 binary license, I didn't find the 7 or 8
    onein a quick google search. 
    
    
    
    
    
    --
    john r pierce                                      37N 122W
    somewhere on the middle of the left coast
    
    
    
    

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

    From
    cowwoc
    Date:
    On 18/09/2014 3:17 PM, John R Pierce [via PostgreSQL] wrote:
    On 9/18/2014 11:44 AM, cowwoc wrote:
    >
    > Yes, that's what I meant. I just wanted to reinforce the fact that you
    > don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick
    > one and bundle it alongside PG and pl/java.

    I think a lawyer would have to pick apart the JRE redistribution license
    to confirm that this use case is acceptable...   the catch-22 is that
    pljava is running user java modules, not just the software its being
    distributed with, and I'm not sure the redistribution license allows that.

    specifically...

    > License  to   Distribute   Software.  Subject to ..., Oracle grants you ... license ... to ... distribute the Software ..., provided that (i) you distribute the Software ... only bundled as part of, and for the sole purpose of running, your Programs, (ii)...

    its that 'sole purpose' part that I wonder about.   FWIW, thats from the JRE 6 binary license, I didn't find the 7 or 8 one in a quick google search.

    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: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    Guy Rouillier
    Date:
    On 9/18/2014 2:44 PM, cowwoc wrote:
    > Yes, that's what I meant. I just wanted to reinforce the fact that you
    > don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick
    > one and bundle it alongside PG and pl/java.
    
    I've been following along as an interested observer, having used PL/Java
    in the past, and developing with Java for a living.  I don't think
    bundling is a good idea.  Gili, as you fully understand, Java is a
    moving target.  Important vulnerabilities are discovered and updates are
    pushed out to address.  So, any bundled version would be subject to
    possibly rapid obsolescence.  Then there are organizational constraints
    or concerns.  Some will only use official JDKs from Oracle/Sun, others
    will only use OpenJDK.  Some won't move to a new major version until at
    least the .1 release, others stick with their Java 6 company-wide
    standard even though that version is officially EOL'd.
    
    So, in my opinion the least contentious way to go would be to have a set
    of instructions that inform the end user to install the JDK or JRE of
    their choice, subject to defined constraints.  Then make PL/Java as
    painless as possible to install.  This should not be a problem with
    larger organizations, since most use centrally-administered software
    configuration.
    
    Thanks.
    
    --
    Guy Rouillier
    
    ---
    This email is free from viruses and malware because avast! Antivirus protection is active.
    http://www.avast.com
    
    
    
    

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

    From
    cowwoc
    Date:
    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

    On 18/09/2014 3:40 PM, Guy Rouillier-4 [via PostgreSQL] wrote:
    On 9/18/2014 2:44 PM, cowwoc wrote:
    > Yes, that's what I meant. I just wanted to reinforce the fact that you
    > don't need to bundle multiple JVMs (Oracle, OpenJDK and GCJ). You'd pick
    > one and bundle it alongside PG and pl/java.

    I've been following along as an interested observer, having used PL/Java
    in the past, and developing with Java for a living.  I don't think
    bundling is a good idea.  Gili, as you fully understand, Java is a
    moving target.  Important vulnerabilities are discovered and updates are
    pushed out to address.  So, any bundled version would be subject to
    possibly rapid obsolescence.  Then there are organizational constraints
    or concerns.  Some will only use official JDKs from Oracle/Sun, others
    will only use OpenJDK.  Some won't move to a new major version until at
    least the .1 release, others stick with their Java 6 company-wide
    standard even though that version is officially EOL'd.

    So, in my opinion the least contentious way to go would be to have a set
    of instructions that inform the end user to install the JDK or JRE of
    their choice, subject to defined constraints.  Then make PL/Java as
    painless as possible to install.  This should not be a problem with
    larger organizations, since most use centrally-administered software
    configuration.

    Thanks.

    --
    Guy Rouillier

    ---
    This email is free from viruses and malware because avast! Antivirus protection is active.
    http://www.avast.com



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



    If you reply to this email, your message will be added to the discussion below:
    http://postgresql.1045698.n5.nabble.com/Why-isn-t-Java-support-part-of-Postgresql-core-tp5819025p5819541.html
    To unsubscribe from Why isn't Java support part of Postgresql core?, click here.
    NAML



    View this message in context: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    Shaun Thomas
    Date:
    On 09/17/2014 11:30 PM, Tom Lane wrote:
    
    > But here's the *key* reason: if pl/java is failing to stay afloat as
    > an external project, that is a terrible reason for pulling it into
    > core.  It suggests strongly that the manpower or interest to keep it
    > going simply doesn't exist.
    
    This is really all that needs to be said, IMO. If it's not in core now,
    after *several years* of existing in various states of completeness on
    its own... it probably isn't going to be. If there can't be a solid
    deployment process *independent* of whatever state Java is in at any
    arbitrary moment, it has no business being in core.
    
    This is clearly a third-party module effort, as are many on PGXN. That
    is fine, honestly. What is wrong with something being an external
    module? Why does everything, including the kitchen sink of Java, need to
    be in core?
    
    It sounds like Mr. Cowwoc has some kind of issue with the maintainers of
    Pl/Java, and he should take it up with them.
    
    --
    Shaun Thomas
    OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
    312-676-8870
    sthomas@optionshouse.com
    
    ______________________________________________
    
    See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
    
    
    

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

    From
    David G Johnston
    Date:


    On Thu, Sep 18, 2014 at 4:00 PM, cowwoc [via PostgreSQL] <[hidden email]> wrote:
    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: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    Shaun Thomas
    Date:
    On 09/18/2014 03:26 PM, David G Johnston wrote:
    
    > There is a lot that can be done in this area but someone - and not
    > the core developers - needs to champion the cause; providing or
    > asking for specific core enhancements to be made as integration
    > problems arise. Then help the various packagers create the packages
    > needed for end-users to easily install the final result on their
    > system
    
    Amen. There are a trillion versions of Java in various states of
    deprecation, vendor, and target platform. This isn't Mono or .NET. I'd
    hate to be the dev team in charge of wrangling that mess into the PG
    build-farm. Ugh.
    
    --
    Shaun Thomas
    OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
    312-676-8870
    sthomas@optionshouse.com
    
    ______________________________________________
    
    See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
    
    
    

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

    From
    cowwoc
    Date:
    On 18/09/2014 4:26 PM, David G Johnston [via PostgreSQL] wrote:
    ​ "only PostgreSQL uses it" ... PostgreSQL doesn't use Java.

    I don't think it makes a difference from a licensing point of view. The point is that the JRE is not used to run multiple distinct applications.

    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: Re: Why isn't Java support part of Postgresql core?
    Sent from the PostgreSQL - general mailing list archive at Nabble.com.

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

    From
    Merlin Moncure
    Date:
    On Wed, Sep 17, 2014 at 11:42 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
    > Tom,
    >
    > For starters, let's talk strictly about improving the deployment situation,
    > which the core team *is* uniquely positioned to do.
    >
    > The pl/java author(s) should figure out what needs to be done but once
    > that's known we need to do *something* in core so the deployment process is
    > reduced to 1-2 steps max (CREATE EXTENSION pljava, and add Java to
    > Postgresql's library path)
    
    You've got it exactly backwards.  'core' should include as little as
    possible.  In fact, many things that are in contrib (for example
    passwordcheck) today are holdovers from when standards of acceptance
    to contrib were lower.
    
    Rather than throwing the kitchen sink into core, IMSNO i would be a
    much better investment to spend efforts on expanding 'CREATE
    EXTENSION' so that it could do things like connect to internet
    repositories and install precomplied libraries.
    
    In lieu of that, if you wanted to make pl/java more accessible the
    first place I'd suggest going to the repository maintainers like pgdg
    and doing everything possible to help them get pl/java building and
    packaged.
    
    merlin
    
    
    

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

    From
    Edson Carlos Ericksson Richter
    Date:

    On 18-09-2014 17:58, cowwoc wrote:
    On 18/09/2014 4:26 PM, David G Johnston [via PostgreSQL] wrote:
    ​ "only PostgreSQL uses it" ... PostgreSQL doesn't use Java.

    I don't think it makes a difference from a licensing point of view. The point is that the JRE is not used to run multiple distinct applications.

    ​Also, there is no functional difference between a public and a private JRE.​  Pointing pl/java to a private JRE is no more or less secure than pointing it to whatever public JRE the administrator happens to have installed.


    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

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

    From
    Szymon Guz
    Date:


    On 18 September 2014 22:58, cowwoc <cowwoc@bbs.darktech.org> wrote:

    Hi,
    I'm observing the whole discussion, and I really don't like the idea of adding everything to the core.

    I fully agree that the core should be small, as small as possible. The way it works now is that it provides interfaces to the external languages like perl or python. This way we could add pljava to the core, but as the normal procedural language. Just next to plperl and plpython. There are just interfacese to external interpreters of perl, python and tcl. There could be another to the external java. But external, not in core.

    There is nothing special in java, that's just another language like perl, python and tcl. I don't see any reason to treat that differently.

    I think we could add the pljava to the core, but not with jre.

    If there should be jre why will java be treated specially? Why not add python, perl, and tcl there? In all possible versions? Why just use one version, which will not be used by all programmers?

    Adding external binaries to the core provides many questions like:
    - which version of the language interpreter/vm? All of them?
    - why one language should be treated specially?
    - what if I want to use two separate versions for two databases in the same cluster?

    If there is a programmer who cannot install jvm/jdk on its own (which is a couple of clicks on windows and linux) then I'm sure that writing stored procerures in java will be even too difficult.

    I think that the good things for java and postgres would be:
    - improve pljava so it works without any problems (if there are any things to be fixed, I don't know that, but someone wrote in this thread that there are some problems)
    - add pljava to the pgxn
    - promote it by some nice examples
    - when pljava would be in the core, then we could add additional info to the official postgres documentation
    - improve jdbc driver, which is currently a huge bunch of terribly unreadible code which doesn't follow any of the modern java conventions and has a couple of jdbc things not implemented (I know, there are too little programmers for this project, there are historical issues, and the driver just works - works but it's hard to modify)
    - create a library to do some more complicated administration things from java, which would be nice, as I observed too many java programmers who are really afraid of touching any database administration

    And of course the one small remark about Postgres. It's an open source project, everybody can fix it, add things he or she thinks are needed. The things then can be added to the core, or not. For instance Pavel wrote a patch for unicode border lines in psql which was on his page for some long time before merging that to the core, and I was using the patch on my own, and it was quite nice.

    I think the first steps for java in postgres should be testing and fixing pljava outside the core. Then there should be nice and readible procedure for installing that. We could add information about this external procedural language to the official postgres documentation without any problem.

    If someone is smart enough to write a procedure in java, I'm sure there won't be problems with installing jre/jdk and adding the extension.
     
    You want PostgreSQL to pick a single implementation of Java and make it accessible via the pl/java language so that people can write triggers in Java instead of pl/pgsql.  What I don't understand is whether you expect those triggers to call out to other Java code that the trigger writers may have written?  That they would is being assumed and those external Java programs are what will have been tested, by the user, on specific combinations of JRE and OS that PostgreSQL may not be providing.

    Let's talk about a concrete example. You're worried that PG will invoke MyTrigger.java which uses Google Guava under the hood, and Guava (in turn) will not run properly on the specific vendor/version we support? This is Java we're talking about. There are very few incompatibilities between JVM vendors and version and the ones that exist are very manageable. I don't see a problem with picking a single implementation and telling users their code must be compatible with it. In the past 12 years of working with Java I have not once run across an incompatibility that was caused by the JVM. Every single time, it was a problem with user code making assumptions which were not guaranteed by the specification (i.e. their own problem).


    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

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

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

    I agree with most of what you said. I will only comment on the differences:

    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.

    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.

    On 19/09/2014 3:18 AM, Szymon Guz wrote:
    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.

    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.

    I also don't like the idea that you want to stick to just one implementation. Let's assume that postgres will have java 1.7 for the next 10 years. Just because someone made the decision. Any java 1.8 code which uses the new java features will not run on this machine, and the user will not be able to use its own jvm with his own procedures written in this new java version. And then one day there will be an incompatible java release most people are talking about, what then?
    1. The oldest dependency I see in the "lib" directory is from 2012. What makes you believe they would refuse to update a dependency for 10 years? A private JRE is just a library. It's no different from anything else.
    2. The user can still replace the JRE themselves if they need to. This is less user friendly, but it's doable.
    I really like the idea that users can just link postgres with anything they want. Postgres will have just interface, and the things it will link to will be provided by the users.

    I'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

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

    From
    Szymon Guz
    Date:


    On 19 September 2014 10:19, cowwoc <cowwoc@bbs.darktech.org> wrote:
    I am beginning to feel like people are putting words in my mouth :)

    I agree with most of what you said. I will only comment on the differences:

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

    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

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

    From
    Chris Travers
    Date:
    These are minor nitpicks but they address significant questions about the scope of core.

     
    On Fri, Sep 19, 2014 at 1:19 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
    I am beginning to feel like people are putting words in my mouth :)

    I agree with most of what you said. I will only comment on the differences:

    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.


    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.

    On 19/09/2014 3:18 AM, Szymon Guz wrote:
    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.



    --
    Best Wishes,
    Chris Travers

    Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.

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

    From
    cowwoc
    Date:
    On 19/09/2014 4:30 AM, Szymon Guz wrote:
    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.

    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.

     
    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.


    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

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

    From
    Dmitriy Igrishin
    Date:


    2014-09-15 9:22 GMT+04:00 cowwoc <cowwoc@bbs.darktech.org>:
    Hi,

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

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

    What's going on? Why isn't this a core language supported alongside SQL,
    Perl and Python as part of the core project?
     Out of curiosity and what's going on? Why there is no Common Lisp
    in PostgresSQL's core? :-)


    --
    // Dmitriy.

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

    From
    Rob Sargent
    Date:
    On 09/19/2014 02:10 PM, Dmitriy Igrishin wrote:


    2014-09-15 9:22 GMT+04:00 cowwoc <cowwoc@bbs.darktech.org>:
    Hi,

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

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

    What's going on? Why isn't this a core language supported alongside SQL,
    Perl and Python as part of the core project?
     Out of curiosity and what's going on? Why there is no Common Lisp
    in PostgresSQL's core? :-)


    --
    // Dmitriy.

    Dmitri, please be careful.  Your risking all the emacs users chiming in!

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

    From
    Chris Travers
    Date:


    On Fri, Sep 19, 2014 at 1:10 PM, Dmitriy Igrishin <dmitigr@gmail.com> wrote:


    2014-09-15 9:22 GMT+04:00 cowwoc <cowwoc@bbs.darktech.org>:
    Hi,

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

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

    What's going on? Why isn't this a core language supported alongside SQL,
    Perl and Python as part of the core project?
     
     Out of curiosity and what's going on? Why there is no Common Lisp
    in PostgresSQL's core? :-)

    Armed Bear Common Lisp should be accessible from pl/java right?
    *ducks* 


    --
    // Dmitriy.




    --
    Best Wishes,
    Chris Travers

    Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.