I didn’t have it right ;-) It turns out a JarFile stream of versioned entries was more interesting than I initially thought. Here’s another webrev. It’s not clear to me if I should include the change to JarFile in this changeset or if it should be in a stand alone changeset. Advice appreciated.
webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.02/ <http://cr.openjdk.java.net/~sdrach/8156499/webrev.02/> > On Aug 9, 2016, at 5:41 PM, Steve Drach <steve.dr...@oracle.com> wrote: > > >> On Aug 8, 2016, at 12:46 PM, Alan Bateman <alan.bate...@oracle.com >> <mailto:alan.bate...@oracle.com>> wrote: >>> >> I think we can do this in phases, starting out with jlink picking up the >> runtime version and using that to select the resources from the modular JAR >> would be a good start. At some point we will have an update module path >> implementation that better supports link time, in which case you can find >> java.base and then use its version (as opposed to the runtime version) when >> finding modules. > > I think I have it right this time. It’s much more complex unfortunately. > > webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.01/ > <http://cr.openjdk.java.net/~sdrach/8156499/webrev.01/> > issue: https://bugs.openjdk.java.net/browse/JDK-8156499 > <https://bugs.openjdk.java.net/browse/JDK-8156499> > >>> The issue has to do with multi-release jar files. How do exploded images >>> relate to multi-release jar files. >>> >>> >> If you look at the other jlink tests then you'll see that they skip silently >> when on an exploded image (no packaged modules, meaning no JMOD files). > > I couldn’t really find what you were referring to, other than a possibility > in BascTest, so what I did is assure the module path only has the Mr. Jar > file and jmods. It’s possible that isn’t what you are looking for >
