Barry Lind <blind@xythos.com> writes:
> I am not sure I follow. Are you suggesting:
> 1) create function takes java source and then calls gcj to compile it
> to native and build a .so from it that would get called at runtime?
> or
> 2) create function takes java source and just compiles to java .class
> files and the runtime invokes the gcj java interpreter.
> or I guess you could do both at the same time.
The impression I had (after not looking very closely) was that you could
expect to compile to bytecodes on the fly and then run the gcj
interpreter. But the .so alternative might be a good fallback if that
doesn't work.
> 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 ...
> 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?
regards, tom lane
