Detecting non-1.5 Java code while developing on a mac under 1.6

I use a mac (and therefore java 1.6) to develop a cross-platform application that is released in Java 1.5. I've discovered that Eclipse can enforce 1.5 compliance, and that has saved me from publishing some code with 1.6-style @Override syntax. However, eclipse's compliance-detection is limited to syntax. It will not catch functions. I used the 1.6 String.isEmpty() method, for example, which built and ran with no warnings in Ecl开发者_如何学编程ipse and at my mac's commandline, but then broke when moved over to our 1.5 linux machines.

Is there a way, perhaps something I could run on the jar files after building, or any other way, to catch 1.6-isms I've slipped in, without leaving my mac?

Good question. My suggestion would be to properly configure your project's build path in Eclipse to point to the 1.5 libraries.

First, install a 1.5 JDK or JRE. Then, go to the Properties for your Eclipse project. Under Java Build Path, click on the Libraries tab, find the entry labelled "JRE System Library." Edit that entry to point to an "Alternate JRE" (you might have to click on "Installed JREs" to tell Eclipse where the JRE is first). Choose your 1.5 JRE.

This should utilize a Java 5 rt.jar which has only the 1.5 API.

If you are using Maven, then that's exactly what animal sniffer is for.

If you are developing a project which must support running on JDK version 1.4, but your development system does not have a JDK version 1.4 available, it can be quite easy to accidentally use methods or classes that are only available in the newer version of the JDK. For example, if you are developing a plugin for Maven 2.0.x on a newer Macintosh.

Animal sniffer can check the classes and method signatures that your compiled code uses and verify that you have use only those classes and signatures available in the API you are targetting.

What stops you from using 1.5 java version on Mac Box. I have mac machine and it has java 1.5 and 1.6 versions both. In case you are unable to find its location, its at: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home

This answer is a hack, and completely untested, but it should work.

When Eclipse compiles your code, it uses the rt.jar and tools.jar belonging to the current and/or specified JRE. You could copy your "normal" JDK into a new directory, and substitute the JARfiles from a Linux/Windows 1.5 distribution. Add that JRE to Eclipse (in Preferences) as an alternate, and switch to it when you want to verify your code.

The only really thorough thing would be to install a 1.5 JDK and compile with that. If you can't install an old version of java on OS X, then install VirtualBox, install Linux in that, and install java on that. This sounds like a mental thing to do - it probably is a mental thing to do - but it's actually pretty straightforward, and it gives you an absolutely watertight build.

If you compile via javac as normal there is a command line option -source release Java Oracle doc that Specifies the version of source code accepted.

Thus to build only using 1.5 use -source 5 or -source 1.5

Assuming you upgraded to OSX 10.6 from 10.5, you should have JDK v1.5 installed alongside JDK 1.6 otherwise you can download it from Apple.

Then you can then build the app using ant and JDK 1.5. Note that ant relies on the value you set for the JAVA_HOME environment variable.

You could for instance edit your /Users/name/.bash_profile to include these values based on the actual path to where your JDKs are installed:

JAVA_HOME_14=/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Home
JAVA_HOME_15=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
JAVA_HOME_16=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home

export JAVA_HOME=$JAVA_HOME_15
PATH=$PATH:$HOME/bin:$JAVA_HOME/bin

So when you need to switch to JDK 1.6 simply swap the

export JAVA_HOME=$JAVA_HOME_15

with:

export JAVA_HOME=$JAVA_HOME_16

I use DependencyFinder for this purpose. This first analyses bytecode of all classes in my jar file and extracts all dependencies. As a result, an XML report is generated containing all classes, constructors, methods, and member attributes referenced by my application.

This XML report is then filtered in two steps:

1. Keep only classes, constructors, methods, and member attributes in the namespaces I want to check. In my case, java.* and javax.*.
2. Exclude all classes, constructors, methods, and member attributes that do appear in a 'whitelist' that lists all valid symbols for the given JDK release (e.g. 1.5)

If the resulting report, after filtering, contains any class, constructor, method, or member attribute (i.e., if this is not empty), then the build is aborted -- this means you are using APIs not supported by your target JDK release.

Sounds a bit verbose but works very well in practice, and does not depend on your IDE settings (which is not practical when several developers work on the same project). I have an ant macro that automates this task, although ant is of course not actually required for this solution.