Hi,
Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de Loof and me
met Brian Goetz and discussed about the objective of JEP 238 and what we could
get from such a feature.
Having a face to face explanation in front of a white board gave interesting
ideas: then, *as library maintainer*, I tried to modifiy plexus-utils code to
use MVJAR for Java 7 enhancement that are currently triggerred through
reflection
Here is the result [1]:
I extracted 2 little xxxMv classes containing only the few methods that had to
be enhanced when runing on Java 7, replacing the
if (Java7Detector.isJava7()) {
// java 7
} else {
// Java 5
}
stanza with the default Java 5 code in the main src/main/java source tree
and Java 7 reimplementation in src/main/java-7 source tree
and I did cleanup: removed Java7Detector and moved NioFiles to this java-7
specific source tree
the result is a main src/main/java source tree that can be compiled with JDK 5
and a src/main/java-7 source tree that is minimal to be compiled with JDK 7
I still didn't try to update pom.xml to see what maven-compiler-plugin and
maven-jar-plugin configurations could look like.
and I don't know if javac will be enhanced to do the 2 compilations in 1
command like "javac -target 1.5 src/main/java -target 1.7 src/main/java-7" or
if it'l have to launch 2 javac one after the other
I didn't look at maven-jar-plugin to see if it uses "jar" command that will be
enhanced to mix multiple target/classes or if it uses JarFile class then will
need to code the mix
and I don't know if javac will have tru crossplatform compilation option, to
avoid using 2 JDKs (ie JDK 5 for compiling java 5 code and being sure there is
no Java 7 API reference, and JDK 7 for the java 7 part)
I see there will be impact on tooling, and if javac does a part of the job,
this will be a lot easier to implement at Maven level
But at the moment, my objective was not from Maven point of view but library
developper point of view: show a real world case of how an existing library
could be refactored to use the feature, expecting that the new source code
would be easier to maintain
WDYT?
Regards,
Hervé
[1]
https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main/java-7/org/codehaus/plexus/util
Le jeudi 19 mars 2015 23:38:32 Robert Scholte a écrit :
> Hi,
>
> we've been asked to give our opinion on the JEP 238: Multi-Version JAR
> Files
>
> Here's a quote from Rory O'Donnels e-mail:
> ---
> It's goal is to extend the JAR file format to allow multiple, JDK
> release-specific versions of class
> files to coexist in a single file. An additional goal is to backport the
> run-time changes to
> JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a
> detailed discussion,
> please see the corresponding thread on the core-libs-dev mailing list. [1]
>
> Please keep in mind that a JEP in the Candidate state is merely an idea
> worthy of consideration
> by JDK Release Projects and related efforts; there is no commitment that
> it will be delivered in
> any particular release.
>
> Comments, questions, and suggestions are welcome on the corelibs-dev
> mailing list. (If you
> haven’t already subscribed to that list then please do so first,
> otherwise your message will be
> discarded as spam.)
>
> [0] http://openjdk.java.net/jeps/238
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031461.ht
> ml
>
> ---
>
> IIUC the original request was to have different version of the same class
> within the same artifact. On the mailinglist I noticed a more interesting
> idea: you need a mechanism to map Classes, Methods or Fields from one
> version to the other.
>
> From a Maven perspective I don't see that much issues with the original
> idea. You should already be able to do it right now with a lot of
> execution-blocks.
> However, I don't see how users would maintain different version of the
> same class (within an IDE).
> To me this all looks quite complex for rare cases.
> If you really want multiple JDK versions of the same artifact, I would
> probably split them into classified artifacts.
>
> Any other comments?
>
> thanks,
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
