Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > JDK1.6 won't compile my JDK1.5 code

Reply
Thread Tools

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

 
 
Mark Rafn
Guest
Posts: n/a
 
      06-30-2009
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?
--
Mark Rafn http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.dagon.net/>
 
Reply With Quote
 
 
 
 
Frank Langelage
Guest
Posts: n/a
 
      06-30-2009
Mark Rafn wrote:
> 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?
> --
> Mark Rafn (E-Mail Removed) <http://www.dagon.net/>


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.
 
Reply With Quote
 
 
 
 
Andrew Thompson
Guest
Posts: n/a
 
      06-30-2009
On Jul 1, 4:52*am, Mark Rafn <(E-Mail Removed)> wrote:
>
> 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.

--
Amdrew T.
pscode.org
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      06-30-2009
Mark Rafn wrote:
> 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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      06-30-2009
Frank Langelage wrote:
> Mark Rafn wrote:
>> 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?
>> --
>> Mark Rafn (E-Mail Removed) <http://www.dagon.net/>

>
> 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
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      06-30-2009
On Tue, 30 Jun 2009 18:52:17 +0000 (UTC), Mark Rafn <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>
>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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-01-2009
Roedy Green wrote:
> On Tue, 30 Jun 2009 18:52:17 +0000 (UTC), Mark Rafn <(E-Mail Removed)>
> wrote, quoted or indirectly quoted someone who said :
>> 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?


Why don't you check yourself in:
http://java.sun.com/javase/6/docs/ap...e-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
 
Reply With Quote
 
Kevin McMurtrie
Guest
Posts: n/a
 
      07-01-2009
In article <h2dmt1$1g6$(E-Mail Removed)>, Mark Rafn <(E-Mail Removed)>
wrote:

> 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?
> --
> Mark Rafn (E-Mail Removed) <http://www.dagon.net/>


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.

--
I will not see your reply if you use Google.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-01-2009
On Tue, 30 Jun 2009 20:51:04 -0400, Arne Vajh°j <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>
>(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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-01-2009
Roedy Green wrote:
> On Tue, 30 Jun 2009 20:51:04 -0400, Arne Vajh°j <(E-Mail Removed)>
> wrote, quoted or indirectly quoted someone who said :
>> (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.


Maybe.

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

Arne
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
compile directive for conditional compile for Java 1.4 versus Java 5 timjowers Java 7 02-02-2011 12:08 AM
How to compile the following source code in VC6// I have error inVC++6 but compile ok in GCC fAnSKyer C++ 2 06-07-2009 07:57 AM
computation at compile time i.e. compile time functions usingtemplates Carter C++ 2 03-04-2009 06:43 PM
Compile versus not compile (VS 2005)?? stupid48@gmail.com ASP .Net 1 04-11-2008 08:24 PM
cant compile on linux system.cant compile on cant compile onlinux system. Nagaraj C++ 1 03-01-2007 11:18 AM



Advertisments