On 02/25/2015 11:41 AM, Paul Sandoz wrote:
On Feb 25, 2015, at 5:27 PM, Brian Goetz <brian.go...@oracle.com> wrote:
On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
Interesting direction.
Reading carefully, the goal is actually very limited in scope, by
preventing any public API changes. It doesn't help adoption of JSR-310
for example, but will be useful for Unsafe, which is clearly a
motivating factor.
I would expect IDEs to have some considerable work to do.
Agree on the "work" part, but I doubt it is "considerable".
For creating MV JARs, the 'jar' tool does all the heavy lifting.
For running Java apps, the classloader does all the heavy lifting.
For tools that have to consume JARs, the JarFile API does all the heavy
lifting. If you use JarFile, it's a one-line change to the constructor to get
a version-specific view of the JAR.
So in each of these cases, the work is limited to:
- Figure out how you intend to interact with MVJars;
- Configure the appropriate tool (jar tool, JarFile) appropriately; this is
generally a matter of new constructor arguments and/or new command line
arguments.
So I totally agree there will be lots of things that change, but those changes
should be individually quite small (and this is consistent with our experience
supporting MVJars in the JDK tools.)
In the design doc i outlined how to explicitly compile an mv-style project.
How hard would it be to hack up a new kind of maven project layout and javac
compilation task that did something similar?
Does anybody with maven expertise know more?
I've done a little bit of work on the maven-compiler-plugin internals
and its plexus buddies, and overall I don't think this would necessarily
be a massive undertaking, though it might have to be, depending on some
factors:
1) If the JDK-agnostic sources are required to be fully self-contained
(i.e. no "outward" dependencies on JDK-specific code), it would be
trivial to compile the JDK-agnostic code first, then the JDK-specific
code which references the other code as dependencies. However this
arrangement is practically quite useless for the average developer who
is doing this just so they could have just one JDK-specific version of
some class used by their main code.
2) In the more likely case that the -specific and -agnostic code is
interdependent, it gets trickier because the compiler task would have to
(I guess) compile the code N times, once for each JDK, while also
correlating the -specific files and discarding the redundant -agnostic
files (leaving aside weirdness that may occur if the files actually
*differ* due to constant expansion weirdness and so on). This thought
leaves me feeling not so great - it seems like there are many subtle
ways it could fail.
3) The best scenario however is that JavaCompiler will magically do all
this work for us, figuring out (for example) the constant stuff and
other potential weirdness, and then organizing the resultant .class
files in their appropriate places based on some input
configuration/cooperation with the JavaFileManager for the task. In
this case I'd imagine that the maven-compiler-plugin would work as
today, with just a few extra switches to point out the JDK-specific
source directories, and Maven would be blissfully ignorant of any other
considerations.
--
- DML
