Re: [INTERFACES] 1.2 JVM and such

On Mon, 30 Nov 1998, Dallas Hockley wrote:

> Greetings all,
>
> Just focusing on a sub topic here. I just browsed the JDBC 2.0 API
> spec, and it looks like the main issue is ability to compile the
> driver. Correct me if I'm wrong, but the new Driver, as Peter stated,
> will largely have *more* methods in the existing classes, and a few new
> supporting classes and types. The 1.2 JVM will support both drivers, as
> stated in the spec.

Except that someone has already tried, and it fails.

Now, I've only browsed the 1.2 documentation, and most of the Interfaces
(except java.sql.Driver) have had either additional methods, or
depreciated ones.

The problem seems to be the 1.2 class validator checks the classes as they
are being loaded, and generates an exception when it sees that not all
methods are implemented.

> I think that the integration of the 1.2/JDBC 2.0 spec into the driver is
> the "right thing", but the JVM issue is still at the heart of the
> matter. I think the distribution of the binary classes as both a 1.1x
> and 1.2 jar file will be needed, due to the post which reflects the
> reality that not too many of us have multiple JVMs on the platforms.

It depends on what has changed in the class format. When 1.1 first
appeared, there was differences in the class file format, which meant that
1.0.2 couldn't run 1.1 compiled classes, but 1.1 could run 1.0.2 classes.

The trick we could use, is to compile for 1.2 (which would be in a
separate sub-package), then recompile for 1.1 (which would include the
original classes).

As java.sql.Driver hasn't changed, our implementation of it would stay as
postgresql.Driver, hence not breaking any existing user code, but it would
then check the VM version, and then either call postgresql.Connection for
1.1, or say postgresql.v2.Connection for 1.2

Until I can get my hands on 1.2, I won't know if this will be possible,
but the more I think about it, it should work.

> Our shop is using the 1.1 and postgresql pretty intensely here, but if
> we can move to the 1.2, especially with the additional functionality the
> JDBC 2.0 spec represents in BLOBs, and fixed meta and type classes, as
> well as new result sets capabilities, it may be a case where the 1.1
> development is frozen except for bug fixes anyway. I don't know if that
> is the intent, but it makes sense from my point of view.

That's why I started this thread. I wanted to find out what everyone else
thought about this.

There's two ways: either have two drivers, one for 1.1 the other for 1.2,
or have an integrated source tree, with the makefile handling the
autodetection of the active vm when make is called, and it then calls two
rules, jdbc1 and jdbc2 for the two sets.

I'm still thinking of the latter method, as it means that our extension
classes (postgresql.fastpath, postgresql.geometric, etc) will only exist
in one place (they are unaffected by this), and at most, we would only
have to re-work the Driver class.

> Now, my rambling does have one other purpose. Would a 1.2 compiled
> binary work on a 1.1 system/app/applet anyway? It appears to me that it
> would from a theoretical standpoint, as the interface additions and new
> classes wouldn't be used. However, the internal algorithms and
> interactions may make the assumption incorrect.

As I said earlier, it would depend on if the class file format is
different or not.

A good sign, is that on the javalinux list, there are reports of people
using the 1.2 classes on a 1.1.x VM, so it may well work.

However, to keep the driver nice & tidy, I don't want to see hacks where
to compile the driver you need 1.2, when you want to run it on 1.1 (1.1
will be around for some time - look at how long 1.0.2 has survived!)

Peter

--
Peter T Mount peter(at)retep(dot)org(dot)uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf