Josh Berkus wrote:

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.

Thomas Hallgren

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to