Comments on: Java 6 breaks JDBC http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/ Frank Carver's musings about software and life Sun, 22 Jan 2012 22:15:12 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Malcolm McRoberts http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-2229 Malcolm McRoberts Tue, 16 Jun 2009 12:56:24 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-2229 I'm also pissed by this change. Not many folks have the luxury to leave in a pure environment where versions aren't mixed. Anybody tried the stub library for the new types? I'm being forced to do a lot of busywork here that doesn't contribute to the functionality I'm trying to build. I'll look at the dynamic proxy mechanism, but unless something's going to generate the code for me, it looks like a ton of overhead and code to write. Is there a way to do a mixed version that's normal static methods for the common operations, and a dynamic proxy for the extensions? I’m also pissed by this change. Not many folks have the luxury to leave in a pure environment where versions aren’t mixed. Anybody tried the stub library for the new types? I’m being forced to do a lot of busywork here that doesn’t contribute to the functionality I’m trying to build.

I’ll look at the dynamic proxy mechanism, but unless something’s going to generate the code for me, it looks like a ton of overhead and code to write.

Is there a way to do a mixed version that’s normal static methods for the common operations, and a dynamic proxy for the extensions?

]]> By: Vladimir Nesterovsky http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-593 Vladimir Nesterovsky Sun, 12 Oct 2008 13:22:13 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-593 Isn't it possible to create a small jar with missing types. You won't probably need to deploy it, or if you will then for old runtime only. Isn’t it possible to create a small jar with missing types. You won’t probably need to deploy it, or if you will then for old runtime only.

]]> By: Heinz Kabutz http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-356 Heinz Kabutz Tue, 30 Sep 2008 17:27:47 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-356 Dynamic Proxies might be of help here. I have not done it, but you might be able to generate classes dynamically that implement the published interface without actually writing the code. This way you could be compatible with whatever version of JDK / JDBC you are using. Dynamic Proxies might be of help here. I have not done it, but you might be able to generate classes dynamically that implement the published interface without actually writing the code. This way you could be compatible with whatever version of JDK / JDBC you are using.

]]> By: henk http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-245 henk Thu, 25 Sep 2008 12:37:17 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-245 @Frank I hear you and maybe I am living in a different world, but what we always do is update everything early, so we never have giants leaps to take. When we were on Java 5 for example, we did not upgrade any of the libraries we were depending on to versions that were released after Java 6 was released. After about half a year after Java 6 was released, we started a test procedure to see if our own code could run on it and if all libraries we were using were compatible with it. Backwards compatibility appeared to be really great. After some extensive tests, everything appeared to work and believe me, we are using LOTS of 3rd party libraries. After the upgrade to Java 6, we started upgrading our libraries to the latest versions, piece by piece. Everything kept working. That's why I don't really see the problem. Of course, sometimes there really are backwards compatibility problems. JBoss 4.2 comes to mind. It really seems to me though that some people have the idea that upgrading the JVM is 'evil' or 'dangerous', but upgrading major libraries can always be done. I don't really agree with that line of reasoning. If you don't want to upgrade your VM, why would you want to upgrade to the very latest version of something huge like e.g. Hibernate? @Frank

I hear you and maybe I am living in a different world, but what we always do is update everything early, so we never have giants leaps to take. When we were on Java 5 for example, we did not upgrade any of the libraries we were depending on to versions that were released after Java 6 was released. After about half a year after Java 6 was released, we started a test procedure to see if our own code could run on it and if all libraries we were using were compatible with it. Backwards compatibility appeared to be really great. After some extensive tests, everything appeared to work and believe me, we are using LOTS of 3rd party libraries.

After the upgrade to Java 6, we started upgrading our libraries to the latest versions, piece by piece. Everything kept working. That’s why I don’t really see the problem. Of course, sometimes there really are backwards compatibility problems. JBoss 4.2 comes to mind.

It really seems to me though that some people have the idea that upgrading the JVM is ‘evil’ or ‘dangerous’, but upgrading major libraries can always be done. I don’t really agree with that line of reasoning. If you don’t want to upgrade your VM, why would you want to upgrade to the very latest version of something huge like e.g. Hibernate?

]]> By: PaulK http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-233 PaulK Wed, 24 Sep 2008 22:32:25 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-233 Groovy solves this using the Proxy technique similar to that described by Geert. It was the only way to make Groovy DataSets seamlessly work across 1.4, 5 and 6. You can check out the source code if you want some ideas. Groovy solves this using the Proxy technique similar to that described by Geert. It was the only way to make Groovy DataSets seamlessly work across 1.4, 5 and 6. You can check out the source code if you want some ideas.

]]> By: Kelly http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-230 Kelly Wed, 24 Sep 2008 18:50:52 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-230 If you're doing something like making a Connector wrapper or decorator, you can use dynamic proxies to create code that overrides the methods you care about and compiles on all three versions. http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html If you’re doing something like making a Connector wrapper or decorator, you can use dynamic proxies to create code that overrides the methods you care about and compiles on all three versions.

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html

]]> By: Frank http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-228 Frank Wed, 24 Sep 2008 15:46:44 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-228 @henk If it were just a compatibility problem between Java 1.4 and Java 6, I could go with your reasoning. However, in this case the problem is between Java 5 and Java 6. And if you think that everyone has already upgraded all of their source code from working with Java 5 to requiring Java 6 then you are living in a very different world to me. If the new types (NClob and so on) had been introduced in Java 5, then the JDBC interfaces changed to use them in Java 6, I would be happy. But introducing both at the same time in Java 6 leads inevitably to the problems I describe above. @henk
If it were just a compatibility problem between Java 1.4 and Java 6, I could go with your reasoning.

However, in this case the problem is between Java 5 and Java 6. And if you think that everyone has already upgraded all of their source code from working with Java 5 to requiring Java 6 then you are living in a very different world to me.

If the new types (NClob and so on) had been introduced in Java 5, then the JDBC interfaces changed to use them in Java 6, I would be happy. But introducing both at the same time in Java 6 leads inevitably to the problems I describe above.

]]> By: henk http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-226 henk Wed, 24 Sep 2008 14:51:44 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-226 I don't understand your problem. People who want to keep using an ancient version of Java, will probably also want to use ancient versions of the libraries they're using. Why should the latest release of some library still be compatible with something as old as Java 1.4? Do you honestly think people who still run Java 1.4 will upgrade -anything-? Most likely they will just be using the versions of all libraries that were current when Java 1.4 was still new and shiny. I don’t understand your problem. People who want to keep using an ancient version of Java, will probably also want to use ancient versions of the libraries they’re using.

Why should the latest release of some library still be compatible with something as old as Java 1.4? Do you honestly think people who still run Java 1.4 will upgrade -anything-?

Most likely they will just be using the versions of all libraries that were current when Java 1.4 was still new and shiny.

]]> By: Frank http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-221 Frank Wed, 24 Sep 2008 09:46:09 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-221 @Geert Bevin That's the kind of direction I was thinking of. The main problem is with managing the source code. I typically develop in Eclipse, which (AFAIK) only supports one Java version setting per project. This implies that in order to edit and compile these different variants I need to set up multiple Eclipse projects for a single final jar. I guess it's doable, but certainly clumsy. @Geert Bevin
That’s the kind of direction I was thinking of.

The main problem is with managing the source code. I typically develop in Eclipse, which (AFAIK) only supports one Java version setting per project. This implies that in order to edit and compile these different variants I need to set up multiple Eclipse projects for a single final jar.

I guess it’s doable, but certainly clumsy.

]]> By: Frank http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/comment-page-1/#comment-220 Frank Wed, 24 Sep 2008 09:40:03 +0000 http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc/#comment-220 @Guy Korland I'd not heard of those. I'll definitely take a look. Thanks @Guy Korland
I’d not heard of those. I’ll definitely take a look. Thanks

]]>