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.