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 Eclipse 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?

8 Answers
8

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.

That may be, I don't use Mac. But if that's the case, I don't understand why you "agree" with akb's answer, which is basically "have both Java 5 and Java 6 installed (on the Mac box)."
–
Mark PetersSep 21 '10 at 19:57

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

@Thorbjørn: I disagree with that approach, as that sets the global default for that workspace. Better to leave the default as your primary JRE but override it at the project level.
–
Mark PetersSep 21 '10 at 18:16

@Mark, he wants his code to run under 10.5. Setting the global default is the easiest and safest way to ensure that.
–
Thorbjørn Ravn AndersenSep 21 '10 at 19:28

Wait, are your steps in your first comment meant to be taken from Eclipse or are they some OS setting? Maybe that's why I'm confused, because you can set the default JRE from "Windows->Preferences->Java->Installed JREs" so I assumed you were talking about Eclipse. If you're talking about Eclipse, it's no "safer" (or easier, really) to set it globally than at the project level, and by doing it at the project level you correctly identify the fact that it's a certain product or component that is targeted for Java 1.5, not "all code I'll ever write."
–
Mark PetersSep 21 '10 at 20:05

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.

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:

Keep only classes, constructors, methods, and member attributes in the namespaces I want to check. In my case, java.* and javax.*.

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.