Re: PG functions in Java: maybe use gcj?

Tom Lane wrote:
> Barry Lind <blind@xythos.com> writes:
> 
>>In either case I am concerned about licensing issues.  gcj is not under 
>>a BSD style license.  Depending on what you need you are either dealing 
>>with regular GPL, LGPL, or LGPL with a special java exception.
>>I beleive (without giving it too much thought) that doing either 1 or 2 
>>above would end up linking GPL code into postgres.  This can be worked 
>>around by requiring the the necessary gcj libraries be installed 
>>separately and detected at configure time (like is done elsewhere).  But 
>>is does (I think) present a problem for commercial products that would 
>>like to redistribute postgres with pljava.
> 
> 
> Good point, but unless you want to build a BSD-license Java
> implementation, there will never be a pljava that doesn't have different
> licensing restrictions than PG itself does.  gcj is at least more free
> than either Sun's or IBM's JVM ...
> 

It depends on what you mean by more free.  An architecture that 
interacts with an external jvm would let you use any jvm (free ones as 
well as others).  From a licensing standpoint it is generally easy to 
redistribute a jvm or expect the user to have one installed (most java 
based products out there today do this).

However in the proposal here we are talking about requiring a specific 
jvm (gcj) and actually linking parts of it into postgres.  To the extent 
that GPL code is linked in the GPL extends to the entire code base.  As 
I said previously there are ways to work around this, but it becomes 
tricky.  Especially when a commercial product wants to bundle postgres 
and pljava.  That resulting bundle is probably entirely under the GPL 
and then any changes to it are also GPL.  So it could be the case that 
this company would be prevented from submitting improvements they made 
back to the core product because their improvements are GPLed as a 
result of pljava.

Now having said all that, I have been monitoring the progres of gcj for 
some time because I think there are very interesting possibilities.  And 
I am all for anyone who wants to look into it further and investigate 
the possiblities.  I just want to raise the licensing issue because it 
can cause problems and it is better to think about them up front than 
after the fact.

> 
>>Another challenge here it that the java code is going to want to use the 
>>jdbc api when communicating with the database.
> 
> 
> Yes.  I think we'd need a new implementation of jdbc that sits atop SPI
> (invoked via jni I guess) rather than a FE/BE connection.  How well
> layered is our jdbc code --- would this mean a large rewrite, or just
> rolling in a new bottom layer?
> 

It isn't as well layered as it could be, but it isn't too bad.  Overall 
it shouldn't be too much work, but not a little project either.  One 
area that isn't well layered is the assumption that the raw data from 
the server is in text format, since that is what the FE/BE protocol 
provides.  So all the conversion functions that convert to/from java 
datatypes do so in this format.  This assumption runs deep into the 
code.  As a first pass it would be easiest to get raw data from SPI 
convert to text and then convert to java datatypes instead of going 
directly from the internal SPI format directly to java datatypes.  This 
could be improved upon later.

>             regards, tom lane
> 

thanks,
--Barry