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? Paul.
