In short/middle term the lack of IDE integration isn't a real problem for
now.
Like Brian said, they know that users won't use such feature before several
years.
The runtime part providing the compatibility for the JRE should be
backported to Java 8 but only Java 9 JDK will provide required tools to
create such jars.
The goal to involve build tools ASAP is to validate the technical
feasibility to integrate such new feature before J9 is out (and not to wait
for its delivery to do it - and complain when it will be too late)
What we need to do here is to imagine how it will be in 2/3? years when
we'll start to have developers using a JDK9 who'll want to provide
librairies compatible (and optimized) for previous JREs.
For me (in my dreams) it should clearly be in only one module and thus
probably with additional sources directories. The compiler plugin should
hide (in one or several steps) the compilation of sources and the jar
packaging should discover if it has to create a mvjar or not
On Sat, Apr 11, 2015 at 11:21 AM, nicolas de loof <nicolas.del...@gmail.com>
wrote:
> This was part of the discussion we had with Brian,
>
> The need for "some way" to address multi-JDK target environment without
> just using the poorest API is a common thing for tools/framework/library
> developers. They use to rely on complex profile-based maven builds,
> hack-ish ant/gradle scripts, etc and produce -jdk6 / -jdk7 classified
> artifacts. This JEP offer a nice alternative, but this for sure only make
> sense if adopted by development tools.
>
> I thing Maven is the one who can help this being a success. If maven do
> support multi-version source directories, then for sure Idea will embrace
> this and Eclipse as well (but probably later #troll)
>
> In the meantime, lack of IDE support is for sure an issue.
> BUT considering JDK7/8/9 features are in most case encapsulated into some
> utility class which offer an alternate implementation on lower JDK, and
> this is not something you have to work on a daily basis, you can just
> configure IDE with the lowest JDK level and ignore errors in the java-7 /
> java-8 source tree which only contain some optimized code (or exclude from
> IDE), and (temporary) switch to higher JDK when you need to edit them.
>
> As Hervé said, the impact on compiler/jar/resource/surefire plugin has to
> be explored, but could probably be implemented today as a PoC with some
> dozen lines of plugin executions xml config. I plan to experiment with the
> runtime classloader which is able to load the adequate class file depending
> on runtime JDK to setup a demo.
>
>
>
>
>
> 2015-04-11 10:54 GMT+02:00 Kristian Rosenvold <
> kristian.rosenv...@gmail.com>
> :
>
> > IDE support for multiple source trees seems quite far off ?
> >
> > Kristian
> >
> >
> > 2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > > 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
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
