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

Discussion in 'Java' started by Mark Rafn, Jun 30, 2009.

  1. Mark Rafn

    Mark Rafn Guest

    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.dagon.net/>
    Mark Rafn, Jun 30, 2009
    #1
    1. Advertising

  2. 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 <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.
    Frank Langelage, Jun 30, 2009
    #2
    1. Advertising

  3. On Jul 1, 4:52 am, Mark Rafn <> 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
    Andrew Thompson, Jun 30, 2009
    #3
  4. Mark Rafn

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Jun 30, 2009
    #4
  5. Mark Rafn

    Arne Vajhøj Guest

    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 <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
    Arne Vajhøj, Jun 30, 2009
    #5
  6. Mark Rafn

    Roedy Green Guest

    On Tue, 30 Jun 2009 18:52:17 +0000 (UTC), Mark Rafn <>
    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
    Roedy Green, Jun 30, 2009
    #6
  7. Mark Rafn

    Arne Vajhøj Guest

    Roedy Green wrote:
    > On Tue, 30 Jun 2009 18:52:17 +0000 (UTC), Mark Rafn <>
    > 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/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
    Arne Vajhøj, Jul 1, 2009
    #7
  8. In article <h2dmt1$1g6$>, 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 <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.
    Kevin McMurtrie, Jul 1, 2009
    #8
  9. Mark Rafn

    Roedy Green Guest

    On Tue, 30 Jun 2009 20:51:04 -0400, Arne Vajhøj <>
    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
    Roedy Green, Jul 1, 2009
    #9
  10. Mark Rafn

    Arne Vajhøj Guest

    Roedy Green wrote:
    > On Tue, 30 Jun 2009 20:51:04 -0400, Arne Vajhøj <>
    > 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
    Arne Vajhøj, Jul 2, 2009
    #10
  11. Mark Rafn

    Arne Vajhøj Guest

    Kevin McMurtrie wrote:
    > In article <h2dmt1$1g6$>, Mark Rafn <>
    > wrote:
    >> 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!


    > I'm not a fan of JDBC 6 either.


    JDBC 4.0

    Arne
    Arne Vajhøj, Jul 2, 2009
    #11
  12. In article <4a4beb06$0$48232$>,
    Arne Vajhøj <> wrote:

    > Kevin McMurtrie wrote:
    > > In article <h2dmt1$1g6$>, Mark Rafn <>
    > > wrote:
    > >> 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!

    >
    > > I'm not a fan of JDBC 6 either.

    >
    > JDBC 4.0
    >
    > Arne


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

    --
    I will not see your reply if you use Google.
    Kevin McMurtrie, Jul 2, 2009
    #12
  13. Arne Vajhøj <> wrote:
    > Roedy Green wrote:
    >> [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.
    Andreas Leitgeb, Jul 2, 2009
    #13
  14. Mark Rafn

    anijap

    Joined:
    Jul 2, 2009
    Messages:
    1
    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!
    anijap, Jul 2, 2009
    #14
  15. Andreas Leitgeb wrote:
    > Arne Vajhøj <> wrote:
    >> Roedy Green wrote:
    >>> [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
    Arne Vajhøj, Jul 5, 2009
    #15
  16. Arne Vajhøj <> wrote:
    >>>> [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.
    Andreas Leitgeb, Jul 5, 2009
    #16
  17. Andreas Leitgeb wrote:
    > Arne Vajhøj <> wrote:
    >>>>> [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
    Arne Vajhøj, Jul 5, 2009
    #17
  18. Arne Vajhøj <> wrote:
    > 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)
    Andreas Leitgeb, Jul 5, 2009
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michal M
    Replies:
    7
    Views:
    777
    Andrew Thompson
    Aug 2, 2005
  2. Replies:
    3
    Views:
    5,149
    Bjorn Abelli
    Mar 30, 2006
  3. manzur
    Replies:
    5
    Views:
    488
    Chris Uppal
    Nov 9, 2006
  4. Replies:
    0
    Views:
    714
  5. Nagaraj
    Replies:
    1
    Views:
    840
    Lionel B
    Mar 1, 2007
Loading...

Share This Page