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

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Why isn't Java support part of Postgresql core?
Дата
Msg-id CAHyXU0yoFxwH=YgkWtX62BXKsRHUNwXx+C6+boMvizu1Y472sQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why isn't Java support part of Postgresql core?  (Chris Travers <chris.travers@gmail.com>)
Ответы Re: Why isn't Java support part of Postgresql core?  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-general
On Mon, Sep 15, 2014 at 6:03 AM, Chris Travers <chris.travers@gmail.com> wrote:
>
>
> On Sun, Sep 14, 2014 at 10:22 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>
>> Hi,
>>
>> Out of curiosity, why is Postgresql's Java support so poor? I am
>> specifically looking for the ability to write triggers in Java.
>
>
> Because it hasn't been a priority of contributors.  This is how
> non-single-vendor open source projects work: people decide what is important
> to them and do the work required.  If something gets neglected then I guess
> it wasn't really important.
>>
>>
>> I took a look at the PL/Java project and it looked both incomplete and
>> dead,
>> yet other languages like Javascript are taking off. I would have expected
>> to
>> see very strong support for Java because it's the most frequently used
>> language on the server-side.
>
> I think Javascript is taking off because JSON is taking off.  The problem
> with Java is that while there are plenty of use cases for it in the db, it
> isn't something which there are *common* use cases for.

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

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

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

merlin


В списке pgsql-general по дате отправления:

Предыдущее
От: cowwoc
Дата:
Сообщение: Re: Feature request: temporary schemas
Следующее
От: Rob Sargent
Дата:
Сообщение: Re: Feature request: temporary schemas