JDK1.6 won't compile my JDK1.5 code

[Mark Rafn]

This is mostly me whining, rather than asking for help. Sorry.

Why oh why would they change the java.sql.Connection interface in a
non-compatible way without even documenting the change?

I use a custom Connection class, which basically wraps the Connection I get
from my JDBC pool, but does logging of usage and gives diagnostics for
unclosed connections. It's a pretty trivial wrapper that just logs and
delegates to the real Connection.

But it doesn't compile under jdk1.6. There's about 10 new methods in
Connection, which I don't have implementations for. They're easy to add, but
then it doesn't compile under jdk1.5, as the methods don't exist in the
delegation object!

Grr! So now I'm back in the C world of conditional compilation - actually
using different source for different compilers. Or I'm dealing with ugly
Reflection code to work around methods that may or may not be missing.

Would it have been that much harder for Sun to have extended Connection rather
than just changing it in place?

 

[Frank Langelage]

This is mostly me whining, rather than asking for help. Sorry.

Why oh why would they change the java.sql.Connection interface in a
non-compatible way without even documenting the change?

I use a custom Connection class, which basically wraps the Connection I get
from my JDBC pool, but does logging of usage and gives diagnostics for
unclosed connections. It's a pretty trivial wrapper that just logs and
delegates to the real Connection.

But it doesn't compile under jdk1.6. There's about 10 new methods in
Connection, which I don't have implementations for. They're easy to add, but
then it doesn't compile under jdk1.5, as the methods don't exist in the
delegation object!

Grr! So now I'm back in the C world of conditional compilation - actually
using different source for different compilers. Or I'm dealing with ugly
Reflection code to work around methods that may or may not be missing.

Would it have been that much harder for Sun to have extended Connection rather
than just changing it in place?

The methods added to the interface with version 6 are marked with "since
1.6". So the change is obvious in the API doc.

I can't fully understand what you're doing (Connection is an Interface!,
the JDBC driver provides a class which implements it, how does your
class interact with that?) but you might want to study javac options
-source, -target and -bootclasspath.

 

[Andrew Thompson]

But it doesn't compile under jdk1.6.  

You need to explore the -source, -target, and most
importantly, the -bootclasspath options of javac.

Using JDK 1.6, you can compile code for any earlier
JRE, so long as you have access to the rt.jar for that
version. ..

..This is mostly me whining, rather than asking
for help. Sorry.

... So stop whining, no apologies and RTFM.

 

[Arne Vajhøj]

This is mostly me whining, rather than asking for help. Sorry.

Why oh why would they change the java.sql.Connection interface in a
non-compatible way without even documenting the change?

I use a custom Connection class, which basically wraps the Connection I get
from my JDBC pool, but does logging of usage and gives diagnostics for
unclosed connections. It's a pretty trivial wrapper that just logs and
delegates to the real Connection.

But it doesn't compile under jdk1.6. There's about 10 new methods in
Connection, which I don't have implementations for. They're easy to add, but
then it doesn't compile under jdk1.5, as the methods don't exist in the
delegation object!

Grr! So now I'm back in the C world of conditional compilation - actually
using different source for different compilers. Or I'm dealing with ugly
Reflection code to work around methods that may or may not be missing.

Would it have been that much harder for Sun to have extended Connection rather
than just changing it in place?

We had this discussion just a few months ago.

A JDBC driver should be compiled with a JDK that has the same
JDBC version as the driver is written for.

They could have decided to have Connection, Connection21, Connection30
and Connection40 interfaced but they did not. It would not have been
pretty if they had.

You are not back to different source - you are back to
different JDK's.

If the call of your code had needed the new features then it would
not have compiled before.

Arne

 

[Arne Vajhøj]

The methods added to the interface with version 6 are marked with "since
1.6". So the change is obvious in the API doc.

I can't fully understand what you're doing (Connection is an Interface!,
the JDBC driver provides a class which implements it, how does your
class interact with that?)

I think the key phrase was:
"I use a custom Connection class"
which must mean "I have a class that implements Connection".

but you might want to study javac options
-source, -target and -bootclasspath.

I would use an older version of the JDK for building the driver instead
of messing with those options.

Arne

 

[Roedy Green]

Would it have been that much harder for Sun to have extended Connection rather
than just changing it in place?

You implemented the interface from scratch. Usually Sun has "adapter"
classes that have dummy stubs for the methods you MUST implement
yourself and default ones for the rest.

Is there such as adapter class you could extend to implement your JDBC
driver?

--
Roedy Green Canadian Mind Products
http://mindprod.com

"Deer hunting would be fine sport, if only the deer had guns."
~ William S. Gilbert of Gilbert and Sullivan

 

[Arne Vajhøj]

You implemented the interface from scratch. Usually Sun has "adapter"
classes that have dummy stubs for the methods you MUST implement
yourself and default ones for the rest.

Is there such as adapter class you could extend to implement your JDBC
driver?

Why don't you check yourself in:
http://java.sun.com/javase/6/docs/api/java/sql/package-summary.html

(well usually it is the poster that should check, but I assume that
he like almost everybody else knows that there are no such class
in java.sql)

Arne

 

[Kevin McMurtrie]

This is mostly me whining, rather than asking for help. Sorry.

Why oh why would they change the java.sql.Connection interface in a
non-compatible way without even documenting the change?

I use a custom Connection class, which basically wraps the Connection I get
from my JDBC pool, but does logging of usage and gives diagnostics for
unclosed connections. It's a pretty trivial wrapper that just logs and
delegates to the real Connection.

But it doesn't compile under jdk1.6. There's about 10 new methods in
Connection, which I don't have implementations for. They're easy to add, but
then it doesn't compile under jdk1.5, as the methods don't exist in the
delegation object!

Grr! So now I'm back in the C world of conditional compilation - actually
using different source for different compilers. Or I'm dealing with ugly
Reflection code to work around methods that may or may not be missing.

Would it have been that much harder for Sun to have extended Connection rather
than just changing it in place?

I'm not a fan of JDBC 6 either.

Implementations using a Proxy were easy enough because they're the union
of a custom interface and the java.sql interface. Anything not in the
custom interface is passed through. Normal implementations need some
right-clicking in Eclipse to fix them.

The new Wrapper interface is something that people are going to hate for
a long time. The documentation is confusing at first and I don't have a
way to test it. It's not forward or backwards compatible so it must be
commented out in Java 1.5. Besides compilation issues, it defeats the
point of wrappers and all the reasons for JDBC being an interface. I
need to be absolutely sure that specific calls are intercepted, like
close(), while maintaining the JDBC API that everybody is familiar with.
Now the API allows a standardized way of defeating that, or causing an
unexpected runtime exception. I'd rather have a non-standard trick for
defeating the wrapper hidden in documentation where bad coders will
never find it.

 

[Roedy Green]

(well usually it is the poster that should check, but I assume that
he like almost everybody else knows that there are no such class
in java.sql)

Perhaps then there should be one.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Deer hunting would be fine sport, if only the deer had guns."
~ William S. Gilbert of Gilbert and Sullivan

 

[Arne Vajhøj]

Perhaps then there should be one.

Maybe.

But I find it very difficult to see what should be in that class.

Arne

 

[Arne Vajhøj]

I'm not a fan of JDBC 6 either.

JDBC 4.0

Arne

 

[Kevin McMurtrie]

JDBC 4.0

Arne

Oops. Changed my stream of thought from JDBC to Java within the space
of only two words.

 

[Andreas Leitgeb]

[Adaptor-classes for those JDBC-interfaces]
Perhaps then there should be one.

Maybe.
But I find it very difficult to see what should be in that class.

Ideally, a delegator-pattern: A constructor that takes a parameter
of the respective interface, and each method just calls the same
Method on the passed target-instance, passing on each of its own
arguments. I admit, though, that this is not the idea behind
"Adaptor"-classes. Instead, the whole point of it would be, that
if Sun extends the interface, *they*'d keep the Delegator-classes
updated, so a user could derive his own class from the respective
Delegator, and override only the methods that he wants to intercept
without having to worry that future new methods in the interface
will cause difficulties when recompiling with future new versions
of the JDK.

It would also be possible to auto-create these Delegators in a
pre-step before compiling the project that would use them,
but I don't know of any existing Interface->Delegator converter,
yet.

 

[anijap]

On Jul 1, 4:52*am, Mark Rafn <[email protected]> wrote:

You need to explore the -source, -target, and most
importantly, the -bootclasspath options of javac.

Using JDK 1.6, you can compile code for any earlier
JRE, so long as you have access to the rt.jar for that
version. ..

--
Amdrew T.
pscode.org

How can I do this?

I am using eclipse and trying to compile code that is using some 1.5 JDBC classes.
I have tried setting the compiler compliance level to 1.5 but still get the same error.
(Connection is abstract; cannot be instantiated)

Any suggestions?

Thanks!

 

[Arne Vajhøj]

[Adaptor-classes for those JDBC-interfaces]
Perhaps then there should be one.

Maybe.
But I find it very difficult to see what should be in that class.

Ideally, a delegator-pattern: A constructor that takes a parameter
of the respective interface, and each method just calls the same
Method on the passed target-instance, passing on each of its own
arguments. I admit, though, that this is not the idea behind
"Adaptor"-classes. Instead, the whole point of it would be, that
if Sun extends the interface, *they*'d keep the Delegator-classes
updated, so a user could derive his own class from the respective
Delegator, and override only the methods that he wants to intercept
without having to worry that future new methods in the interface
will cause difficulties when recompiling with future new versions
of the JDK.

It would also be possible to auto-create these Delegators in a
pre-step before compiling the project that would use them,
but I don't know of any existing Interface->Delegator converter,
yet.

Interesting idea.

But it was not what Roedy was describing.

And I don't think it will solve the compile problem the
thread is about. Assuming that I have understood your idea
correctly.

The class being passed as parameter to the constructor
of the delegating class would have the same problem.

Arne

 

[Andreas Leitgeb]

[Adaptor-classes for those JDBC-interfaces]
But I find it very difficult to see what should be in that class.

Ideally, a delegator-pattern: A constructor that takes a parameter
of the respective interface, and each method just calls the same
Method on the passed target-instance, passing on each of its own
arguments. I admit, though, that this is not the idea behind
"Adaptor"-classes. [...]

But it [the delegators] was not what Roedy was describing.

Indeed. Adapter-classes have different purposes. I was aware of that.

I combined your question about Adapter-classes with the OP (here: "Original
Problem" .

And I don't think it will solve the compile problem the
thread is about.

I do think it would do exactly that.

The DB-interfaces are meant to be "implemented" only by DB-Drivers
and as such it's considered acceptable for them to change, as it is
the DB-drivers' authors' job to update the implementations for each
new JDK (if necessary).

There seems to be some distinction made by java-(class library)
designers between driver-development and application development.
I don't think that interfaces like "Runnable" had any chance of
a new method added, even if there was a use for one.

Application programmers usually don't need to implement e.g.
java.sql.ResultSet - unless they want to intercept some of the
method-calls (like the OP), before calling the foreign actual
implementation.

The class being passed as parameter to the constructor
of the delegating class would have the same problem.

No, because that would be an instance returned by some actual
DB-driver factory method.

E.g.: (assume appropriate imports and context)

ResultSet rs=stmt.executeQuery(query);
ResultSet wrappedRs=new ResultSetDelegator(rs) {
void insertRow() throws SQLException {
Log.... // do some special logging
super.insertRow(); // contains call to rs.insertRow()
}
}

The class ResultSetDelegator could in principle be autogenerated
from ResultSet (given some tool that does it), or it could be part
of java.sql.* and updated whenever ResultSet gets new methods (so
far: at 1.2, 1.4 and 1.6).

The example code could have been developed for JDK1.2 (if the
delegator class had been there, back then, or a tool for producing it)
and would still compile with 1.6+ without a need for manual modification
of this snippet even if other parts of the application were already
using 1.6-API.

 

[Arne Vajhøj]

[Adaptor-classes for those JDBC-interfaces]
But I find it very difficult to see what should be in that class.
Ideally, a delegator-pattern: A constructor that takes a parameter
of the respective interface, and each method just calls the same
Method on the passed target-instance, passing on each of its own
arguments. I admit, though, that this is not the idea behind
"Adaptor"-classes. [...]

But it [the delegators] was not what Roedy was describing.

Indeed. Adapter-classes have different purposes. I was aware of that.

I combined your question about Adapter-classes with the OP (here: "Original
Problem" .

And I don't think it will solve the compile problem the
thread is about.

I do think it would do exactly that.

The DB-interfaces are meant to be "implemented" only by DB-Drivers
and as such it's considered acceptable for them to change, as it is
the DB-drivers' authors' job to update the implementations for each
new JDK (if necessary).

There seems to be some distinction made by java-(class library)
designers between driver-development and application development.
I don't think that interfaces like "Runnable" had any chance of
a new method added, even if there was a use for one.

Application programmers usually don't need to implement e.g.
java.sql.ResultSet - unless they want to intercept some of the
method-calls (like the OP), before calling the foreign actual
implementation.

The class being passed as parameter to the constructor
of the delegating class would have the same problem.

No, because that would be an instance returned by some actual
DB-driver factory method.

E.g.: (assume appropriate imports and context)

ResultSet rs=stmt.executeQuery(query);
ResultSet wrappedRs=new ResultSetDelegator(rs) {
void insertRow() throws SQLException {
Log.... // do some special logging
super.insertRow(); // contains call to rs.insertRow()
}
}

The class ResultSetDelegator could in principle be autogenerated
from ResultSet (given some tool that does it), or it could be part
of java.sql.* and updated whenever ResultSet gets new methods (so
far: at 1.2, 1.4 and 1.6).

The example code could have been developed for JDK1.2 (if the
delegator class had been there, back then, or a tool for producing it)
and would still compile with 1.6+ without a need for manual modification
of this snippet even if other parts of the application were already
using 1.6-API.

OK.

Regular applications that uses JDBC does not have a problem building
on newer JDK's.

Actual JDBC drivers does have a problem building on newer JDK's and
as I read you text above, then your solution does not fix that.

You seem to be fixing the problem for a third type of problem:
having an application intercept certain calls to a real driver.
I am still not sure that I completely understand your concept, but
yes it sounds as if it would solve that problem.

An alternative approach to solving that problem would be to
mess around with an AOP framework like AspectJ.

Arne

 

[Andreas Leitgeb]

Regular applications that uses JDBC does not have a problem building
on newer JDK's. Yes

Actual JDBC drivers does have a problem building on newer JDK's and
as I read you text above, then your solution does not fix that.

Correct. No fix for those, as they must sensibly implement those new
features.

You seem to be fixing the problem for a third type of problem:
having an application intercept certain calls to a real driver.
I am still not sure that I completely understand your concept, but
yes it sounds as if it would solve that problem.

Yes, that's the problem that I addressed. On my counting, however, it
came in first, as it was the OP's problem - intercepting calls to
the DB-driver from an application and coping with the problem that
the interfaces in java.sql.* (unlike most others) grow new methods
every once in a while.

An alternative approach to solving that problem would be to
mess around with an AOP framework like AspectJ.

Maybe - I haven't yet looked into this domain. Perhaps it
actually contains one implementation of such an automatic
delegator-creation tool (among other things)