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.)
