On Thu, Sep 17, 2009 at 5:38 AM, Jess Holle <[email protected]> wrote: [snip]
> > > The discussion did bring up cases where compilation against different JDK > library versions was required. This problem is rather annoying in cases. > For instance, the JDBC Connection API in Java 6 adds a whole lot of methods, > many of which use classes only found in Java 6. Thus if you have a > FilteredConnection class that implements Connection, you have to compile a > different source file if using JDK 5 than for JDK 6 -- there's no > FilteredConnection source that will compile under both. Yes, in this case a > dynamic proxy would work around the issue. Overall, however, there seems to > be an overly cavalier attitude towards growing existing interfaces rather > than adding other interfaces that are used as mixins. JDBC appears to be > the worst case -- forcing one to compile lots of code with Java 5 in order > to run under Java 5 irrespective of -source and -target flags. In the end, > however, this whole mess is different than the -source issue -- and can only > be addressed by considering such issues when making JDK API changes. > Yes, the JDBC API uses a different evolution policy than the rest of the classes in the JDK. One possible mitigation is to use an annotation processor to generate a JDK version dependent superclass with the new methods with JDK 6 type only being generated when compiled against JDK 6. Modularity should also be able to help with cases like this. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
