Question on MVJAR usage

[Steve Drach]

Hi Paul,

> I have some questions. I believe core-lib is the right place. If not please
> let me know.

This is the right place.  First, the name was changed to Multi-Release JAR, so it’s MRJAR (or Mr. Jar) instead of MVJAR.

> 
> 1) Given a Java 9 runtime, is there any perceptible difference between a
> non-multiversion jar, and a versioned jar which has placed all its classes
> under /META-INF/versions/9 ? Pretend each jar has the same identical
> binaries/resources.

There is probably a small difference in performance although I haven’t measured it.  Whether the difference is perceptible or not probably depends on the characteristics of the sensor.

> 
> 2) Does the runtime care if the class version does not match what's under
> /META-INF/versions/9? For example, what if I have targeted a Java 8 class
> file format under versions/9?

The MRJAR runtime does not care.  However if you put a class file targeted for Java 10 in the  /META-INF/versions/9 directory and run it on a Java 9 platform, you’ll probably get an error.

> 
> 3) Why does the new MVJAR JEP writeup [1] use versions/8 in the example?

Because we don’t have a real example that uses Java 9 and the JEP was written when we thought we’d target this feature for Java 8.

> Is
> it simply for illustration, but I don't see how that's a useful example
> since it's an impossibility. There is no MVJAR support prior to Java 8 so
> isn't a better (and realer) example be /9 and /10?

Yes, it would be better, but as I said, we don’t have a real world example yet, so anything we do would be a contrived example.  We probably need to do something with that part of the JEP.

> 
> 3) The same MVJAR JEP writeup doesn't clearly indicate what is considered a
> "platform version". All the examples show a single digit, but I believe
> Verona [2] has specificed the platform to include both major and minor
> versions. For example, Verona says the minor version may include "revisions
> to standard APIs mandated by a Maintenance Release of the relevant Platform
> Specification". Because it mentions platform, it should be possible to do
> /9, /9.0, and /9.1. Please advise?

Platform versions are major versions, i.e. 8, 9, 10, etc.  They are the values derived from Runtime.Version::major

> 
> 4) Although MVJAR JEP writeup says "JAR metadata, such as that found in the
> MANIFEST.MF file and the META-INF/services directory, need not be
> versioned." The keyword here is "need not" which is not the same as "can
> not" or "may not”.

Yes, you are right, it’s incorrect.  Perhaps it should say "JAR metadata, such as that found in the MANIFEST.MF file and the META-INF/services directory, are not versioned.”

> So if it is needed, how does one version different
> services for different platforms?

It can’t be done.

> Can there be /META-INF under the
> appropriate versioned folder?

Technically, it can be done but it won’t be interpreted as a “true” META-INF directory, it’ll just be a path component for the jar entry.

> Maybe /META-INF/versions/9/META-INF?

You won’t achieve what you expect, depending of course on what you expect. ;-)

> I do not
> see anything in the JEP that says it's supported or non-supported. Please
> advise.

It’s not supported.

> 
> [1] http://openjdk.java.net/jeps/238
> [2] http://openjdk.java.net/jeps/223
> 
> Cheers,
> Paul