Re: Three weeks left until feature freeze

mark(at)mark(dot)mielke(dot)cc wrote:
> On the subject of 38K lines of code, much that isn't C (going by memory,
> I apologize if this is wrong), how many of these lines could be/should be
> shared between PL/Java and PL/J? It seems to me that the general concepts
> should be in common, and that it is only how the Java interfaces with the
> backend that changes. Could they not be one PL, with two mechanisms for
> speaking to the backend?
>
By all means. An embedded JVM solution should share as much as possible with one that uses a
remote JVM. From the users perspective there should be no difference at all. PL/Java is
designed with this in mind. The class loader and the utility commands are based on JDBC, the
security manager that enables the choice of trusted/untrusted execution is Java standard. A
set of interfaces for non-standard access (PostgreSQL TriggerData in particular) was
abstracted in order to allow different implementations. Etc.

That said, there is also code that deals with tight backend integration and is highly
specialized to fit the embedded solution. This code is designed around the fact that
function calls to the backend are very cheap. As an example, PL/Java contains a JDBC driver
that is written directly on top of the SPI API. The involved C-structures are rarely copied
or streamed. They are accessed directly using JNI functions.

I've spent some time lately, investigating what it would take to complement PL/Java with a
remote JVM option. The major challenge lays in the impedance mismatch caused by concerns
that one must consider when using RPC (limit the number of calls) compared to the current
design (avoid copying and streaming).

Kind regards,
Thomas Hallgren