Three weeks left until feature freeze

I'd like to submit PL/Java into core for 8.2 if possible. Personally, I see the following
action items to make it happen:

1. A "hackers" discussion to resolve any issues with the submission.

Provided that #1 has a positive outcome:

2. The PL/Java CVS must be moved from gborg and become part of the PostgreSQL CVS (can this
be done with version history intact?).
3. The regression tests need some work in order to fit in with the build farm.
4. Documentation must be ripped from the PL/Java Wiki and transformed into the format used
by PostgreSQL.
5. I'll need committer rights to the PL/Java part in order to maintain it.
6. The pljava-dev mailing list, currently at gborg, must (perhaps) be moved also. An
alternative is to remove it and instead refer to jdbc, general, and hackers.

Given guidance, I'll do the steps #3 and #4.

External dependencies:
Platforms where PL/Java is ported must either support GCJ 4.0 or higher or have a Java
Runtime Environment 1.4.2 or higher installed.

Regards,
Thomas Hallgren

Bruce Momjian wrote:

Thomas Hallgren <thomas@tada.se> writes:

I'd like to submit PL/Java into core for 8.2 if possible. Personally, I see the following
action items to make it happen:

What about licensing issues? Does PL/Java work with any entirely-open-source
JVMs? If not, what is the legal situation for distributing PG+PL/Java?

I'm also a bit concerned about size. By my count, lines of source code:

plpgsql 19890
plperl 4902
plpython 4163
pltcl 4498
pljava 1.3.0 38711

IOW pljava is (already) bigger than the other four PLs put together.

I'm inclined to think that pljava is best off staying as a separate
project.

regards, tom lane

Tom,

Tom Lane wrote:

IOW pljava is (already) bigger than the other four PLs put together.

I'm inclined to think that pljava is best off staying as a separate
project.

I was very confused some recent PL/Java versions can't be compiled
because of PostgreSQL internal changes.

If people think pl/java is important for PostgreSQL,
pl/java should be included in PG core tree,
and should have its regression tests.

I think PL should be integrated with core tightly.

Thanks.
--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
Phone: +81-3-3523-8122

Thomas Hallgren wrote:

5. I'll need committer rights to the PL/Java part in order to maintain
it.

Does our CVS setup cater for seggregated rights like this? Or would that
be done on a trust basis?

cheers

andrew

Tom,

What about licensing issues? Does PL/Java work with any entirely-open-source
JVMs? If not, what is the legal situation for distributing PG+PL/Java?

Actually, Sun has re-licensed the JRE to make it OSS-compatible (it's
now available for Debian, for example) They're doing a Java licensing
session at OSCON if you have any specific questions, or I can ping the
Java Licensing Guru directly. But even if other JRE's aren't supported,
licensing shouldn't be an obstacle.

I'm also a bit concerned about size. By my count, lines of source code:

plpgsql 19890
plperl 4902
plpython 4163
pltcl 4498
pljava 1.3.0 38711

IOW pljava is (already) bigger than the other four PLs put together.

That is odd. Thomas?

I'm inclined to think that pljava is best off staying as a separate
project.

I disagree. One of the things I'm asked by every single tech market
analyst, after replication & clustering, is whether we have support for
procedural Java. So it's something large-scale users want. If PL/Tcl
belongs in the back end, then so does PL/Java.

--Josh Berkus

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of
Andrew Dunstan
Sent: 11 July 2006 15:27
To: Thomas Hallgren
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Three weeks left until feature freeze

Thomas Hallgren wrote:

5. I'll need committer rights to the PL/Java part in order

to maintain

it.

Does our CVS setup cater for seggregated rights like this? Or
would that
be done on a trust basis?

No, I don't believe you can do this with CVS at all. We'd need something
like SVN/WebDAV to be able to grant write access just to specific parts
of the tree to different people.

Regards, Dave.

On Tue, Jul 11, 2006 at 11:21:54PM +0900, Satoshi Nagayasu wrote:

Tom,

Tom Lane wrote:

IOW pljava is (already) bigger than the other four PLs put
together.

I'm inclined to think that pljava is best off staying as a
separate project.

I was very confused some recent PL/Java versions can't be compiled
because of PostgreSQL internal changes.

If people think pl/java is important for PostgreSQL, pl/java should
be included in PG core tree, and should have its regression tests.

I think PL should be integrated with core tightly.

It's good to integrate things with the core as needed. What plans do
we have to integrate PL/J?

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

Andrew Dunstan wrote:

Thomas Hallgren wrote:

5. I'll need committer rights to the PL/Java part in order to maintain
it.

Does our CVS setup cater for seggregated rights like this? Or would that
be done on a trust basis?

Trust.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Josh Berkus wrote:

Tom,

What about licensing issues? Does PL/Java work with any
entirely-open-source
JVMs? If not, what is the legal situation for distributing PG+PL/Java?

Actually, Sun has re-licensed the JRE to make it OSS-compatible (it's
now available for Debian, for example) They're doing a Java licensing
session at OSCON if you have any specific questions, or I can ping
the Java Licensing Guru directly. But even if other JRE's aren't
supported, licensing shouldn't be an obstacle.

I don't see any license issue at all regardless. PL/Java is satisfied
with GCJ 4.0 or higher and compiling with that doesn't affect the binary
more then using gcc does. No JVM is required when using GCJ.

I'm also a bit concerned about size. By my count, lines of source code:

plpgsql 19890
plperl 4902
plpython 4163
pltcl 4498
pljava 1.3.0 38711

IOW pljava is (already) bigger than the other four PLs put together.

That is odd. Thomas?

It's not that odd really:

1. the mapping is strongly typed, i.e. each scalar type in PostgreSQL
has a set of functions that maps it to the correct primitive in Java
(int4 is a java int, double precision is a double etc.). PL/Java will
resort to string coercion only when no other option is left.
2. a type mapping is provided for *all* types. Scalar, composite,
pseudo, array types, and result sets.
3. new Java mappings can be created on the fly. Both for scalar and
composite types.
4. you can create new scalar types in PostgreSQL that uses IO functions
written in Java.
5. the Java code contains it's own API documentation (standard java-doc
comments on classes and methods).
6. the code is written to conform to standard interfaces such as the
JDBC interfaces (from a #lines perspective, perhaps not always the most
optimal way of doing it but it does bring a bunch of other advantages).
7. extensive error handling is included that allow try/catch semantics
when checkpoints are used.
8. extreme measures has been taken to ensure that the backend is never
exposed to more then one thread at a time.
...
(from the top of my head, there are probably more reasons)

IMHO, this is yet another reason to actually include it in core. I'm not
an expert on the other PL's but my guess is that PL/Java is far more
sensitive to API changes in the backend core.

Regards,
Thomas Hallgren

Josh Berkus wrote:

I'm inclined to think that pljava is best off staying as a separate
project.

I disagree. One of the things I'm asked by every single tech market
analyst, after replication & clustering, is whether we have support for
procedural Java. So it's something large-scale users want. If PL/Tcl
belongs in the back end, then so does PL/Java.

We've discussed this before, regarding PL/php IIRC. The conclusions the
last time around, as far as I remember, was that we wanted the PLs to be
in the same CVS repo, but able to be compiled separately from the whole
source tree. So we could sort of rip PL/Perl et al from the actual
backend code, leaving only enough infrastructure to be able to build
them easily (PGXS plus a bunch of stuff, I imagine). PL modules would
follow the backend branches so that there would be no need for pesky
#ifdef PGSQL_VERSION_THIS_OR_THAT stuff; but they would actually be
separate.

The main motivation was that when somebody wants to change an interface
in the backend that's used by PLs, it's useful to change all of them at
the same time instead of waiting until release time comes and the things
does not compile anymore and nobody remembers when or where they were
broken.

I think this would also allow PL/R to be included as well despite the
license, because while it would be in the same repo and editable
together with the backend, it would continue to be a separate project
and thus not contaminate the backend with GPL stuff.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Bruce Momjian wrote:

Andrew Dunstan wrote:

Thomas Hallgren wrote:

5. I'll need committer rights to the PL/Java part in order to maintain
it.

Does our CVS setup cater for seggregated rights like this? Or would that
be done on a trust basis?

Trust.

And pgsql-committers archives ;-)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Does our CVS setup cater for seggregated rights like this? Or
would that
be done on a trust basis?

No, I don't believe you can do this with CVS at all. We'd need something
like SVN/WebDAV to be able to grant write access just to specific parts
of the tree to different people.

It is possible using CVS, by carefully managing file system permissions
and assigning different permissions to the OS users of the different
committers. I guess it's also possible using commit scripts... but I
don't think it worths the effort as long as there is a regular backup of
the CVS tree...

Cheers,
Csaba.

David,

It's good to integrate things with the core as needed. What plans do
we have to integrate PL/J?

None, if the PL/J team doesn't speak up. So far I have yet to see a
request for PL/J or even a release notice.

--Josh

Andrew Dunstan <andrew@dunslane.net> writes:

Thomas Hallgren wrote:

5. I'll need committer rights to the PL/Java part in order to maintain
it.

Does our CVS setup cater for seggregated rights like this? Or would that
be done on a trust basis?

No, and yes. However, I don't have a problem with giving Thomas
committer access --- I'm just dubious about having PL/Java in the
core distro at all.

regards, tom lane

* Josh Berkus (josh@agliodbs.com) wrote:

Actually, Sun has re-licensed the JRE to make it OSS-compatible (it's
now available for Debian, for example) They're doing a Java licensing
session at OSCON if you have any specific questions, or I can ping the
Java Licensing Guru directly. But even if other JRE's aren't supported,
licensing shouldn't be an obstacle.

Uhh.. Let's not go overboard here on exactly what Debian has done with
Sun's JVM. Technically, Sun's JVM is *not* part of Debian. The license
is (and even this is hotly debated...) acceptable enough for Debian's
ftp-masters to allow the Sun JVM to be distributed off Debian servers as
part of the 'non-free' archive. This *certainly* doesn't make it
OSS-compatible by any stretch (it isn't) and it's not acceptable for
inclusion in Debian proper.

I'm actually rather upset to see Sun making such blatently incorrect
statements. Josh, I truely hope that you weren't actually involved in
the Sun JVM-in-Debian work and so were unaware of the very important
distinction between "Distributed by Debian" and "in Debian/main".

Thanks,

Stephen

Snowman,

Uhh.. Let's not go overboard here on exactly what Debian has done with
Sun's JVM. Technically, Sun's JVM is *not* part of Debian. The license
is (and even this is hotly debated...) acceptable enough for Debian's
ftp-masters to allow the Sun JVM to be distributed off Debian servers as
part of the 'non-free' archive. This *certainly* doesn't make it
OSS-compatible by any stretch (it isn't) and it's not acceptable for
inclusion in Debian proper.

I think I can tell which side of the debate you were on.

I'm actually rather upset to see Sun making such blatently incorrect
statements. Josh, I truely hope that you weren't actually involved in
the Sun JVM-in-Debian work and so were unaware of the very important
distinction between "Distributed by Debian" and "in Debian/main".

Keep your pants on, geez. I'm actually rather appalled that you could
get so unjustifiably bent out of shape at me *after* we met. Goes to
show you that not everything is improved by personal acquaintance.

Let's get some stuff clear:

1) I do not speak for Sun execept on specific occasions arranged by Sun
PR. Not ever.

2) If you re-read my message, it says:
... (it's now available for Debian, for example) ...
not ANYTHING about main or distributed or non-free or whatever.

So, I think you owe me an apology.

--Josh

* Josh Berkus (josh@agliodbs.com) wrote:

I think I can tell which side of the debate you were on.

The debate was regarding Sun's JVM being distributed by Debian at all...
There wasn't any debate regarding it's free vs. non-free status so far
as I'm aware. I don't believe there was ever any intention to include
Sun's JVM in Debian/main with it's current license. If you meant
something other than free/non-free by 'OSS-compatible' then you might
have wanted to make that clear since generally that refers to the OSI
Open Source Definition (and/or the DFSG, they're pretty similar tho).

I've not heard 'OSS-compatible' used to refer to 'can run under Linux'
or 'can run on Debian' before. That'd include things like Oracle.

I'm actually rather upset to see Sun making such blatently incorrect
statements. Josh, I truely hope that you weren't actually involved in
the Sun JVM-in-Debian work and so were unaware of the very important
distinction between "Distributed by Debian" and "in Debian/main".

Keep your pants on, geez. I'm actually rather appalled that you could
get so unjustifiably bent out of shape at me *after* we met. Goes to
show you that not everything is improved by personal acquaintance.

Actually, I felt that I pretty clearly gave you the benefit of the
doubt... For many people it's an unfortunate and pretty likely
assumption based on things written on /., etc. It wasn't an attack on
you but rather the frustrated realization that the concerns of many in
Debian regarding Sun's JVM inclusion in non-free may have been justified.

2) If you re-read my message, it says:
... (it's now available for Debian, for example) ...
not ANYTHING about main or distributed or non-free or whatever.

If you hadn't intended to refer to Debian's inclusion of the Sun JVM in
non-free then I'm rather confused since there has been a trivial-to-use
package available in non-free for a long time to download the Sun JVM
from Sun and create debs to install it with. So, it's been available
*for* Debian for a long time, but was only recently put into non-free..
It was also available prior to that, though a pain to install..

You seemed to use the recent change in status of Sun's JVM (at least in
part with regard to Debian...) as justification of your statement that
it's OSS-compatible..

That's exactly the misrepresentation which I was addressing.

So, I think you owe me an apology.

I apologize for being harsher than I should have.

Thanks,

Stephen

Stephen,

You seemed to use the recent change in status of Sun's JVM (at least in
part with regard to Debian...) as justification of your statement that
it's OSS-compatible..

Are you going to be at OSCON? Sun's hosting a BOF to discuss exactly
this issue.

--Josh

On Tuesday 11 July 2006 09:59, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Thomas Hallgren wrote:

5. I'll need committer rights to the PL/Java part in order to maintain
it.

Does our CVS setup cater for seggregated rights like this? Or would that
be done on a trust basis?

No, and yes. However, I don't have a problem with giving Thomas
committer access --- I'm just dubious about having PL/Java in the
core distro at all.

Personally I would like to see in core, but it is not from a technical
perspective. It is purely from a marketing perspective (doubt that carries
much weight here ;)).

Having pl/Java helps PostgreSQL in the minds of all those tie wearing decision
making freaks... and before you say it, No. I do not wear a tie.

Sincerely,

Joshua D. Drake

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/