I've discussed this with the Eclipse JDT team. We're very skeptic and we
think that JEP 238 goes into a wrong direction. Eclipse JDT does not
intend to add special support for it.
Building such MVJARs will be quite complicated, since it requires having
separate classpaths and compiling against multiple JDKs to produce the
release-specific class files that should end up in the same MVJAR. That
means you either need a preprocessor that would allow to keep
JDK-release-specific code in the same *.java file, or you need to
maintain and sync separate *.java files in separate source folders. Both
options are completely counter Java's "write once, run anywhere" idea,
whose foundation is to have only one set of source files and no
platform-specific compilation switches. This is one of the greatest
features of Java. It's what makes reliable code analysis, dependency
tracking, and refactoring possible.
Furthermore, the general problem is not specific to the JDK, but also
occurs for other libraries. Therefore, a JDK-specific solution would be
at the wrong level.
A better solution for such cases is to provide an adapter JAR that makes
the new APIs available when running on an older JDK. That way, the
problem is solved at the origin, and not again and again for each
client. And with "the problem", I mean the problem that the old JDK
release didn't offer an API for something that clients should use ASAP,
even if they can't require the whole new JDK release right away.
Thanks,
Markus Keller
IBM Rational Zurich Research Lab
Eclipse JDT UI
