Skip site navigation (1) Skip section navigation (2)

Re: PG functions in Java: maybe use gcj?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Barry Lind <blind(at)xythos(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: PG functions in Java: maybe use gcj?
Date: 2002-10-31 04:10:28
Message-ID: 3715.1036037428@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Barry Lind <blind(at)xythos(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-10-31 04:40:05
Subject: Re: 7.2.3 vacuum bug
Previous:From: Tom LaneDate: 2002-10-31 03:59:39
Subject: Re: Turning the PLANNER off

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group