Java: easiest way to package both Java 1.5 and 1.6 code

Question

I want to package a piece of code that absolutely must run on Java 1.5. There's one part of the code where the program can be "enhanced" if the VM is an 1.6 VM.

Basically it's this method:

 private long[] findDeadlockedThreads() {
    // JDK 1.5 only supports the findMonitorDeadlockedThreads()
    // method, so you need to comment out the following three lines
    if (mbean.isSynchronizerUsageSupported())
      return mbean.findDeadlockedThreads();
    else
      return mbean.findMonitorDeadlockedThreads();
  }

What would be easiest way to have this compile on 1.5 and yet do the 1.6 method calls when on 1.6 ?

In the past I've done something similar by compiling a unique 1.6 class that I would package with my app and instantiate using a ClassLoader when on 1.6 (because an 1.6 JVM is perfectly fine mixing 0x32 and 0x31 classes), but I think it's a bit overkill (and a bit painful because during the build process you have to build both 0x31 and 0x32 .class files).

How should I go if I wanted to compile the above method on 1.5? Maybe using reflection but then how (I'm not familiar at all with reflection)

Note: if you're curious, the above method comes from this article: http://www.javaspecialists.eu/archive/Issue130.html

(but I don't want to "comment the three lines" like in the article, I want this to compile and run on both 1.5 and 1.6)

Answer 1

You cannot compile this on 1.5, but you can compile on 1.6 with the target-option set to 1.5 (that would produce byte-code for 1.5) and in the code using reflection to find out if the method is available.

This code would lookup the method: mbean.getClass().getMethod("findDeadlockedThreads", new Class[0]); Problem is, it throws an NoSuchMethodException if the method isn't present instead of simply returning null or something similar. That means, you need code like this:

try
{
  mbean.getClass().getMethod("findDeadlockedThreads", new Class<?>[0]);
  return mbean.findDeadlockedThreads();
}
catch(NoSuchMethodException ex)
{
  return mbean.findMonitorDeadlockedThreads();
}

That's not very nice, because it uses an Exception to make an decision. That is probably not very fast. An alternative is to use getMethods instead and iterate over the returned list if your method is available. That's also not very fast.

EDIT: Christopher Oezbek suggests in the comments to make the check for the existence of the method only once and save the result to avoid the overhead for the Try-catch-block. That's right and a good solution. matt b warns, that the target-option of the Java-Compiler doesn't check, if the classes and methods used are available under Java 1.5. That's right (and otherwise it wouldn't work, because you want to compile against a 1.6-method) and that means, that the program should be carefully tested under a 1.5-VM, to avoid this problem. Thanks for your comments both of you.

Answer 2

Compile for 1.5.

In your code use reflection. You can get the Method object from the Class interface; it has an invoke method that takes your mbean instance as a parameter. Something like this:

Class c = mbean.getClass(); // can also do YourClass.class to get this

Method m = c.getMethod("findMonitorDeadLockedThreads"); // or any other method (parameters to the method are specified with Class... second parameter to getMethod)

m.invoke(mbean) // invokes the Method with your instance

Of course you don't have to do this every time; setup the Method references in a constructor and then just invoke the right one on demand.

Answer 3

Maven lets you do this pretty easily with profiles. The idea behind profiles is that you want to build things two different versions of something based on some criteria. In this specific example, you can define a jdk15 and a jdk16 profile, specify which JDK version to compile each with, and tell it to include one copy of the class in the jdk15 profile and the other in jdk16.

To get started, see:

http://unserializableone.blogspot.com/2008/09/compile-and-test-with-different-jdk.html

This describes how to do the different JDK version part of the problem.

To handle the second part of the problem, using a different definition of the class depending on the JDK version, see this:

Maven - Include Different Files at Build Time