pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedJava, JDBC & CORBA (fwd)
10+ messages / 4 participants
[nested] [flat]
* Java, JDBC & CORBA (fwd)
@ 1998-11-26 18:12 Peter T Mount <peter@retep.org.uk>
0 siblings, 0 replies; 10+ messages in thread
From: Peter T Mount @ 1998-11-26 18:12 UTC (permalink / raw)
To: pgsql-interfaces; The Hermit Hacker <scrappy@hub.org>
[I'm resending this as it didn't appear on the list]
---------- Forwarded message ----------
Date: Wed, 25 Nov 1998 21:43:56 +0000 (GMT)
From: Peter T Mount <peter@retep.org.uk>
To: PostgreSQL Interfaces List <pgsql-interfaces@postgreSQL.org>
Subject: Java, JDBC & CORBA
As some of you may, or may not know, the Java JDK 1.2 is due to be
released shortly.
On the CORBA side of things, Java 1.2 provides a CORBA 2.0 orb.
Now I know from the recent postings were concentrating on the CORBA 2.2
api (which I agree with). However, after spending the last few evenings
reading up on CORBA (and someone correct me if I've got the wrong end of
the stick here), if you have two orbs communicating via IIOP, then in most
cases, IIOP would mask out most of the differences between the 2.0 & 2.2
api's?
Anyhow, on to JDBC. We have a problem. Our current JDBC driver (as
reported by Giuliano Carlini <GCARLINI@us.oracle.com>) will not work under
Java 1.2. This is because the java.sql package has been improved, and the
1.2 JVM is now more strict on the classes when it loads.
We could add the missing methods into the existing classes, except that
there are 12 new classes in the java.sql package, and then the driver will
not work (nor compile) with the existing 1.1 JVM.
Now I see two ways round this:
1: We create a new driver, covering the 1.2 additions. I hate this idea,
as it means two separate sets of sources, and I'd expect a lot of confused
users who'll ask "Why two JDBC drivers?"
2: We keep the existing files, and create a new sub-package that includes
the classes that have been changed or added. We can then get the Makefile
to test the JDK version, and then compile the correct set of classes.
Ok, I know there will be two sets of sources for some classes, but this is
the only way I can see to keep backward compatibility with 1.1.x (remember
there are still people using 1.0.2 some 2 years after 1.1 came out -
because the browsers are only just catching up).
One good thing from all this, the java.sql.Driver class has not been
changed, so all existing code will not break when they load our driver.
Anyhow, what method does everyone prefer?
I had to ask this, as it's a major change, and there's a lot of work
that's going to be involved in getting back up to spec.
Peter
--
Peter T Mount peter@retep.org.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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Java, JDBC & CORBA (fwd)
@ 1998-11-30 07:12 Peter T Mount <peter@retep.org.uk>
0 siblings, 0 replies; 10+ messages in thread
From: Peter T Mount @ 1998-11-30 07:12 UTC (permalink / raw)
To: pgsql-interfaces; +Cc: petermount@it.maidstone.gov.uk
Ok, lets see if this gets through to the list this time ;-)
--
Peter T Mount peter@retep.org.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
---------- Forwarded message ----------
Date: Wed, 25 Nov 1998 21:43:56 +0000 (GMT)
From: Peter T Mount <peter@retep.org.uk>
To: PostgreSQL Interfaces List <pgsql-interfaces@postgreSQL.org>
Subject: Java, JDBC & CORBA
As some of you may, or may not know, the Java JDK 1.2 is due to be
released shortly.
On the CORBA side of things, Java 1.2 provides a CORBA 2.0 orb.
Now I know from the recent postings were concentrating on the CORBA 2.2
api (which I agree with). However, after spending the last few evenings
reading up on CORBA (and someone correct me if I've got the wrong end of
the stick here), if you have two orbs communicating via IIOP, then in most
cases, IIOP would mask out most of the differences between the 2.0 & 2.2
api's?
Anyhow, on to JDBC. We have a problem. Our current JDBC driver (as
reported by Giuliano Carlini <GCARLINI@us.oracle.com>) will not work under
Java 1.2. This is because the java.sql package has been improved, and the
1.2 JVM is now more strict on the classes when it loads.
We could add the missing methods into the existing classes, except that
there are 12 new classes in the java.sql package, and then the driver will
not work (nor compile) with the existing 1.1 JVM.
Now I see two ways round this:
1: We create a new driver, covering the 1.2 additions. I hate this idea,
as it means two separate sets of sources, and I'd expect a lot of confused
users who'll ask "Why two JDBC drivers?"
2: We keep the existing files, and create a new sub-package that includes
the classes that have been changed or added. We can then get the Makefile
to test the JDK version, and then compile the correct set of classes.
Ok, I know there will be two sets of sources for some classes, but this is
the only way I can see to keep backward compatibility with 1.1.x (remember
there are still people using 1.0.2 some 2 years after 1.1 came out -
because the browsers are only just catching up).
One good thing from all this, the java.sql.Driver class has not been
changed, so all existing code will not break when they load our driver.
Anyhow, what method does everyone prefer?
I had to ask this, as it's a major change, and there's a lot of work
that's going to be involved in getting back up to spec.
Peter
--
Peter T Mount peter@retep.org.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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [INTERFACES] Java, JDBC & CORBA (fwd)
@ 1998-11-30 14:26 Andrew R. Jackson <ajackson@dezines.com>
1 sibling, 1 reply; 10+ messages in thread
From: Andrew R. Jackson @ 1998-11-30 14:26 UTC (permalink / raw)
To: Peter T Mount <peter@retep.org.uk>; +Cc: pgsql-interfaces
First, let me preface my answer to say that the main reason I am subscribed to this list is to read Peter's, and occassionally others', answers, comments, etc about using JDBC with Postgres.
To answer Peter's question, personally I would prefer two drivers, each separate. The reason for this is that I don't want a Makefile deciding which one (1) will be compiled and installed when I have two (2) different versions of Java on most of the systems I work on (most have 3 Javas, actually). I'd hate to be locked into using one driver version, and thus one Java version for Postgres stuff, because the Makefile only detected one of the Javas (which would be the 1.1.x one for now and some long time into the future). I want to choose. I want to be able to develop a Java 1.1.x solution and a Java 1.2 solution, not either/or.
Now, what really matters is good install instructions. If the instructions included ways to solve problems like the one above, then that's best and I don't care. Nothing beats good, copius, verbose, clear, well-maintained docs. :)
Andrew R. Jackson
<ajackson@dezines.com>
<ajackson@cs.mcgill.ca>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [INTERFACES] Java, JDBC & CORBA (fwd)
@ 1998-11-30 14:48 Herouth Maoz <herouth@oumail.openu.ac.il>
1 sibling, 2 replies; 10+ messages in thread
From: Herouth Maoz @ 1998-11-30 14:48 UTC (permalink / raw)
To: pgsql-interfaces
At 16:26 +0200 on 30/11/98, Andrew R. Jackson wrote:
> First, let me preface my answer to say that the main reason I am
>subscribed to this list is to read Peter's, and occassionally others',
>answers, comments, etc about using JDBC with Postgres.
>
> To answer Peter's question, personally I would prefer two drivers, each
>separate. The reason for this is that I don't want a Makefile deciding
>which one (1) will be compiled and installed when I have two (2) different
>versions of Java on most of the systems I work on (most have 3 Javas,
>actually). I'd hate to be locked into using one driver version, and thus
>one Java version for Postgres stuff, because the Makefile only detected
>one of the Javas (which would be the 1.1.x one for now and some long time
>into the future). I want to choose. I want to be able to develop a Java
>1.1.x solution and a Java 1.2 solution, not either/or.
>
> Now, what really matters is good install instructions. If the
>instructions included ways to solve problems like the one above, then
>that's best and I don't care. Nothing beats good, copius, verbose, clear,
>well-maintained docs. :)
How about a Makefile which has the two (three?) drivers as separate target.
So, I can do a "make 1.1" "make 1.2". If we want to be sophisticated, make
the default tarket (i.e. "make" without args) detect the version of Java on
the current computer, and make the appropriate driver for it.
I just wonder if it's impossible for the driver to load the appropriate
classes dynamically, based on the value of the "java.version" System
property.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [INTERFACES] Java, JDBC & CORBA (fwd)
@ 1998-11-30 15:15 Peter T Mount <peter@taer.maidstone.gov.uk>
parent: Herouth Maoz <herouth@oumail.openu.ac.il>
1 sibling, 0 replies; 10+ messages in thread
From: Peter T Mount @ 1998-11-30 15:15 UTC (permalink / raw)
To: Herouth Maoz <herouth@oumail.openu.ac.il>; +Cc: pgsql-interfaces
On Mon, 30 Nov 1998, Herouth Maoz wrote:
> At 16:26 +0200 on 30/11/98, Andrew R. Jackson wrote:
>
>
> > First, let me preface my answer to say that the main reason I am
> >subscribed to this list is to read Peter's, and occassionally others',
> >answers, comments, etc about using JDBC with Postgres.
> >
> > To answer Peter's question, personally I would prefer two drivers, each
> >separate. The reason for this is that I don't want a Makefile deciding
> >which one (1) will be compiled and installed when I have two (2) different
> >versions of Java on most of the systems I work on (most have 3 Javas,
> >actually). I'd hate to be locked into using one driver version, and thus
> >one Java version for Postgres stuff, because the Makefile only detected
> >one of the Javas (which would be the 1.1.x one for now and some long time
> >into the future). I want to choose. I want to be able to develop a Java
> >1.1.x solution and a Java 1.2 solution, not either/or.
> >
> > Now, what really matters is good install instructions. If the
> >instructions included ways to solve problems like the one above, then
> >that's best and I don't care. Nothing beats good, copius, verbose, clear,
> >well-maintained docs. :)
>
> How about a Makefile which has the two (three?) drivers as separate target.
> So, I can do a "make 1.1" "make 1.2". If we want to be sophisticated, make
> the default tarket (i.e. "make" without args) detect the version of Java on
> the current computer, and make the appropriate driver for it.
The lines I was thinking of was:
Have a target in the makefile that compiles the 1.1 driver, and generates
the current postgresql.jar file.
Have a second target that compiles the 1.2 driver, and generares say
postgresql2.jar
Have a third target that tests to see what jdk is currently available, and
issues the relevent target above.
This would then be the common way of compiling the driver, but it leaves
the ability to compile either one. See below for a possibility.
PS: When JDK1.2 is available for Linux, I will have 1.0.2, 1.1.7 & 1.2
installed (I still rarely use 1.0.2, hence it's still there).
> I just wonder if it's impossible for the driver to load the appropriate
> classes dynamically, based on the value of the "java.version" System
> property.
The postgresql.Driver class will be common between both drivers, for
compatibility reasons. As it's super class (java.sql.Driver) has not
changed, we can keep it unaltered.
Anyhow, I was thinking of adding code so when it creates a connection, it
creates postgresql.Connection when it's 1.1.x, and
postgresql.v2.Connection for 1.2.x
This does open a possibility of having both drivers in the same jar file,
however, it would have to be built using both 1.2 then 1.1 javacs, then
build the jar file.
In theory it should work, but we will have to wait until 1.2 final is out,
before trying it.
--
Peter Mount, IT Section
petermount@it.maidstone.gov.uk
Anything I write here are my own views, and cannot be taken as being the
official words of Maidstone Borough Council
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [INTERFACES] Java, JDBC & CORBA (fwd)
@ 1998-11-30 15:18 Peter T Mount <peter@taer.maidstone.gov.uk>
parent: Andrew R. Jackson <ajackson@dezines.com>
0 siblings, 0 replies; 10+ messages in thread
From: Peter T Mount @ 1998-11-30 15:18 UTC (permalink / raw)
To: Andrew R. Jackson <ajackson@dezines.com>; +Cc: Peter T Mount <peter@retep.org.uk>; pgsql-interfaces
On Mon, 30 Nov 1998, Andrew R. Jackson wrote:
> First, let me preface my answer to say that the main reason I am
> subscribed to this list is to read Peter's, and occassionally others',
> answers, comments, etc about using JDBC with Postgres.
which was why I was asking on Friday why my posts weren't appearing on the
list - now solved.
> To answer Peter's question, personally I would prefer two drivers,
> each separate. The reason for this is that I don't want a Makefile
> deciding which one (1) will be compiled and installed when I have two
> (2) different versions of Java on most of the systems I work on (most
> have 3 Javas, actually). I'd hate to be locked into using one driver
> version, and thus one Java version for Postgres stuff, because the
> Makefile only detected one of the Javas (which would be the 1.1.x one
> for now and some long time into the future). I want to choose. I want
> to be able to develop a Java 1.1.x solution and a Java 1.2 solution,
> not either/or.
Which was why I posted the query. I wanted to find out what everyone
thought (see the other reply).
> Now, what really matters is good install instructions. If the
> instructions included ways to solve problems like the one above, then
> that's best and I don't care. Nothing beats good, copius, verbose,
> clear, well-maintained docs. :)
There's a lot of documentation in the 6.4 docs directory (can't remember
how many pages, but before formatting, it was about 70 pages?).
--
Peter Mount, IT Section
petermount@it.maidstone.gov.uk
Anything I write here are my own views, and cannot be taken as being the
official words of Maidstone Borough Council
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [INTERFACES] Java, JDBC & CORBA (fwd)
@ 1998-11-30 15:26 Herouth Maoz <herouth@oumail.openu.ac.il>
parent: Herouth Maoz <herouth@oumail.openu.ac.il>
1 sibling, 2 replies; 10+ messages in thread
From: Herouth Maoz @ 1998-11-30 15:26 UTC (permalink / raw)
To: Peter T Mount <peter@taer.maidstone.gov.uk>; +Cc: pgsql-interfaces
At 17:15 +0200 on 30/11/98, Peter T Mount wrote:
> Anyhow, I was thinking of adding code so when it creates a connection, it
> creates postgresql.Connection when it's 1.1.x, and
> postgresql.v2.Connection for 1.2.x
>
> This does open a possibility of having both drivers in the same jar file,
> however, it would have to be built using both 1.2 then 1.1 javacs, then
> build the jar file.
>
> In theory it should work, but we will have to wait until 1.2 final is out,
> before trying it.
Yes. That's what I meant.
Another possibility is to provide the driver in binary format. After all,
Java binaries are the same on all platforms.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [INTERFACES] Java, JDBC & CORBA (fwd)
@ 1998-11-30 15:33 Peter T Mount <peter@taer.maidstone.gov.uk>
parent: Herouth Maoz <herouth@oumail.openu.ac.il>
1 sibling, 0 replies; 10+ messages in thread
From: Peter T Mount @ 1998-11-30 15:33 UTC (permalink / raw)
To: Herouth Maoz <herouth@oumail.openu.ac.il>; +Cc: pgsql-interfaces
On Mon, 30 Nov 1998, Herouth Maoz wrote:
> At 17:15 +0200 on 30/11/98, Peter T Mount wrote:
>
>
> > Anyhow, I was thinking of adding code so when it creates a connection, it
> > creates postgresql.Connection when it's 1.1.x, and
> > postgresql.v2.Connection for 1.2.x
> >
> > This does open a possibility of having both drivers in the same jar file,
> > however, it would have to be built using both 1.2 then 1.1 javacs, then
> > build the jar file.
> >
> > In theory it should work, but we will have to wait until 1.2 final is out,
> > before trying it.
>
> Yes. That's what I meant.
>
> Another possibility is to provide the driver in binary format. After all,
> Java binaries are the same on all platforms.
I do on my web site, covering different versions of postgresql. However,
someone tried a 1.1 binary on a 1.2 JVM, and it complained. It's more
strict on the class validation.
--
Peter Mount, IT Section
petermount@it.maidstone.gov.uk
Anything I write here are my own views, and cannot be taken as being the
official words of Maidstone Borough Council
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [INTERFACES] Java, JDBC & CORBA (fwd)
@ 1998-11-30 15:47 Herouth Maoz <herouth@oumail.openu.ac.il>
parent: Herouth Maoz <herouth@oumail.openu.ac.il>
1 sibling, 1 reply; 10+ messages in thread
From: Herouth Maoz @ 1998-11-30 15:47 UTC (permalink / raw)
To: Peter T Mount <peter@taer.maidstone.gov.uk>; +Cc: pgsql-interfaces
At 17:33 +0200 on 30/11/98, Peter T Mount wrote:
> I do on my web site, covering different versions of postgresql. However,
> someone tried a 1.1 binary on a 1.2 JVM, and it complained. It's more
> strict on the class validation.
What I meant was - why not offer the complete bundeled jar (both 1.1 and
1.2, as you suggested) in binary form, and avoid the problem of having to
compile it under two javacs in the target computer. This will force us to
have the two JVMs even if we use onle one... So, do the compilation on your
own set, and distribute the combined Jar. The Jar format itself shouldn't
pose a problem.
Why can you distribute the binaries only from your web site? Any reason you
can't put them in the CVS? Say, in text-encoded format, with the makefile
merely doing the decoding?
I also wonder how come it's impossible to compile 1.1 code under 1.2...
That doesn't make sense, as far as Sun's policy went so far. Perhaps there
is a 1.1 compatibility flag for the 1.2 javac?
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [INTERFACES] Java, JDBC & CORBA (fwd)
@ 1998-11-30 16:15 Peter T Mount <peter@taer.maidstone.gov.uk>
parent: Herouth Maoz <herouth@oumail.openu.ac.il>
0 siblings, 0 replies; 10+ messages in thread
From: Peter T Mount @ 1998-11-30 16:15 UTC (permalink / raw)
To: Herouth Maoz <herouth@oumail.openu.ac.il>; +Cc: pgsql-interfaces
On Mon, 30 Nov 1998, Herouth Maoz wrote:
> At 17:33 +0200 on 30/11/98, Peter T Mount wrote:
>
>
> > I do on my web site, covering different versions of postgresql. However,
> > someone tried a 1.1 binary on a 1.2 JVM, and it complained. It's more
> > strict on the class validation.
>
> What I meant was - why not offer the complete bundeled jar (both 1.1 and
> 1.2, as you suggested) in binary form, and avoid the problem of having to
> compile it under two javacs in the target computer. This will force us to
> have the two JVMs even if we use onle one... So, do the compilation on your
> own set, and distribute the combined Jar. The Jar format itself shouldn't
> pose a problem.
>
> Why can you distribute the binaries only from your web site? Any reason you
> can't put them in the CVS? Say, in text-encoded format, with the makefile
> merely doing the decoding?
There's no reason for them not going into CVS. We had this discussion
before about putting the binary in, but decided not to - can't remember
why though.
I put them up on my site because I was getting asked a lot for the
binaries, and I had a small archive of earlier versions, so I put them up.
If everyone feels that a binary should be in CVS, I can build one every
time I post patches.
Marc, what affects would this have to CVS having a binary in the
repository, and how would it affect updating it later on. Would this cause
more grief than is reasonable?
> I also wonder how come it's impossible to compile 1.1 code under 1.2...
> That doesn't make sense, as far as Sun's policy went so far. Perhaps there
> is a 1.1 compatibility flag for the 1.2 javac?
It's not the JVM, but in 1.2, the java.sql package has been expanded, and
most of the interfaces we implement in the driver have themselves been
expanded, so when you compile the current sources under 1.2, it complains
because methods have not been implemented.
--
Peter Mount, IT Section
petermount@it.maidstone.gov.uk
Anything I write here are my own views, and cannot be taken as being the
official words of Maidstone Borough Council
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~1998-11-30 16:15 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-11-26 18:12 Java, JDBC & CORBA (fwd) Peter T Mount <peter@retep.org.uk>
1998-11-30 07:12 Java, JDBC & CORBA (fwd) Peter T Mount <peter@retep.org.uk>
1998-11-30 14:26 ` Andrew R. Jackson <ajackson@dezines.com>
1998-11-30 15:18 ` Peter T Mount <peter@taer.maidstone.gov.uk>
1998-11-30 14:48 ` Herouth Maoz <herouth@oumail.openu.ac.il>
1998-11-30 15:15 ` Peter T Mount <peter@taer.maidstone.gov.uk>
1998-11-30 15:26 ` Herouth Maoz <herouth@oumail.openu.ac.il>
1998-11-30 15:33 ` Peter T Mount <peter@taer.maidstone.gov.uk>
1998-11-30 15:47 ` Herouth Maoz <herouth@oumail.openu.ac.il>
1998-11-30 16:15 ` Peter T Mount <peter@taer.maidstone.gov.uk>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox