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