Question on MVJAR usage
pbenedict at apache.org
Tue Jul 19 18:48:57 UTC 2016
Thank you Steve. I have only one follow-up then. If the platform version is
*always* a major version, does that imply that minor versions will not add
API? The big benefit of MRJAR :-) is that I can provide separate code for
different targeted runtimes. If 9.1 wouldn't add new API, then I am good.
If that's the policy, great. I just want to confirm it is because I don't
see too much of a technical difference between the two cases (8 to 9 vs 9.0
to 9.1). Does that make sense?
On Tue, Jul 19, 2016 at 1:41 PM, Steve Drach <steve.drach at oracle.com> wrote:
> Hi Paul,
> > I have some questions. I believe core-lib is the right place. If not
> > 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
> > 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  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  has specificed the platform to include both major and minor
> > versions. For example, Verona says the minor version may include
> > to standard APIs mandated by a Maintenance Release of the relevant
> > 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
> > 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.
> >  http://openjdk.java.net/jeps/238
> >  http://openjdk.java.net/jeps/223
> > Cheers,
> > Paul
More information about the core-libs-dev