I am interested in using some of the NIO2 features in the Java 7 SDK if available (specifically, the file system watchers), however I do not want to compile my classes for Java 7 and exclude Java 6 runtimes. Mostly because I want retain compatibility with Mac OS X, and also because I don’t want to force my users to upgrade.
Is this possible? What is the best way to do it? Any links or examples?
Here are some ways I can imagine: compiling a class file with a different compiler and loading it dynamically based on the Java version? Or maybe using reflection? Or maybe there’s just a compiler setting for Java 7 to generate Java 6-compatible classes?
I am looking for a solution that doesn’t turn into an ugly mess :), so ideally I can write two implementations of an interface, one using the new features and one without, and then select one dynamically instead of having to do reflective calls all over the place.
Just build with -target 1.6 and organize your code so you can catch the ClassNotFoundExceptions and NoClassDefFoundErrors cleanly around the modules that use 1.7. Maybe load them with a separate class-loader for example.
You can build for java 1.6 easily as toolkit has pointed out. However, you need to make sure that you don't accidentally access any methods which don't exist in java 6. This will cause a runtime exception in your production code.
If you're using maven, you can use the maven-enforcer-plugin which makes sure that no java 1.7 classes or method calls sneak into your code built for 1.6.
An example would be the change from java 1.4 to 1.5. I was building with 1.5 with a target of 1.4, and I accidentally used:
new BigDecimal(5);
This compiled fine, and ran fine for me. But because the client was still using 1.4, it failed. Because this constructor doesn't exist in 1.4. It was introduced in 1.5.
Another solution would be to build a couple of jars, one with the new nio stuff, one with the old stuff, and detect at installation time whether or not the user was running java 1.7. If so, add the jar that contains the appropriate implementation.
For some elements that were added in Java 7, you might be able to find Java 6 jsr jars that give you the functionality. I do not believe this will be the case for the File System Watcher however.
In terms of file system watchers, before Java 7 I used to just poll a file's properties every few seconds or so to check it hadn't changed. It's not exactly nice, but practically it uses no noticeable resources and from an end user's perspective appears to work the same.
If you're after a more comprehensive library, check out http://commons.apache.org/jci/commons-jci-fam/index.html - I believe that does something similar, though I've never used it.
Specifying source 1.7 and target 1.6 I'm pretty sure won't work, I tried it for a different reason a while back and from memory the JVM complained about incompatible flags (my guess is because of the new invokedynamic in 7.)
来源:https://stackoverflow.com/questions/7598789/using-java-7-sdk-features-in-java-6