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

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(at)bbs(dot)darktech(dot)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.
http://www.efficito.com/learn_more