Yeah- we make heavy use of generics.
Unfortunately we also have a class that implements java.sql.ResultSet
and that seems to have changed between 5 and 6 (now ResultSet extends
Wrapper).

So I think once we make the jump to 1.6, all of our customers will
need to as well.

sc

...

That will not guarantee code compatibility.
See my earliest reply, then RTFM.

Andrew T.

It is more complicated than that because javac uses the java boot class
path to determine the API of the standard libraries. Sun recommend using
javac with the boot class path of the jdk for your target version. In
practice, I find it simpler to just build with the target jdk. Neither
of these approaches will help you if you have used jdk1.6-only library
features and are targeting jre1.5, because the runtime will have no
support for them. The "-target" option (mostly) only affects language
features and the version number of the class files emitted by the compiler.

Here is an example, from the javac manual page for jdk1.6.0:

******

Cross-Compilation Example

    Here we use javac to compile code that will run on a 1.4 VM.

    % javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip \
            -extdirs "" OldCode.java

    The  -target  1.4 option ensures that the generated class files will
    be compatible with 1.4 VMs. By default, javac compiles for JDK 6.

    The Java Platform JDK’s javac would also by default compile  against
    its  own  bootstrap  classes,  so  we  need to tell javac to compile
    against JDK 1.4 bootstrap classes instead. We do  this  with  -boot-
    classpath  and  -extdirs. Failing to do this might allow compilation
    against a Java Platform API that would not be present on  a  1.4  VM
    and would fail at runtime.

******