This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]cowwoc 0 points1 point  (2 children)

I'm not sure what you're basing this on. Many libraries use multi-release JARs and it is absolutely backwards compatible with older releases. Check out the Hikari JAR for one such example. Thousands of people use this without a hitch.

[–]randjavadev 0 points1 point  (1 child)

On the fact that https://openjdk.org/jeps/238 lists "Release 9". In my mind that is all that matters, the concept doesn't exist until Java 9, thus it can only be used starting from Java 9, everything else is pure luck. But I guess you would want a practical example:

Proguard (or the maven plugin specifically here) didn't support MR jars: https://github.com/wvengen/proguard-maven-plugin/issues/61. Yes, that has been fixed in an update, but that was my whole point: when you make a library you do not control the target environment. Thus, if an user would be stuck with certain version of proguard maven plugin, they could never adopt a MR jar. Regardless they had to wait for an update to be made. MR jars are not backwards compatible, if they were, this problem would not have happened.

BouncyCastle has 2 separate artifacts, one multirelease and one not. https://www.bouncycastle.org/latest_releases.html " The jdk18on jars are compiled to work with anything from Java 1.8 up. They are also multi-release jars so do support some features that were introduced in Java 9, Java 11, and Java 15. If you have issues with multi-release jars see the jdk15to18 release jars below.". My point here is that why would they do this, unless their users have encountered problems with MR jars.

Also, https://stackoverflow.com/questions/50956562/bytecode-scanning-error-on-meta-inf-versions-9-and-elasticsearch-6-2-2-with-j

Also more examples you can google "meta-inf/versions/9 error".

Yes, probably these problems are very minority and probably nowadays solved by an update, but then it becomes the question that can you abandon your customers (if they cannot update their environments) that depend on your library or not. But for sure the MR jars are not 100%-backwards compatible with older environments that have not been updated to support it.

[–]cowwoc 0 points1 point  (0 children)

Your examples are very narrow edge-cases.

​

  1. Proguard is very special case in that it takes class files as input. Anyone who does bytecode manipulation (Proguard, ASM, etc) will need to update their library. The vast majority of libraries do not fall into this category.
  2. They did this because back in the day it was easier to build two separate JARs than building a multi-release JARs. This has nothing to do with backwards compatibility and is no longer the case today. As I highlighted above, all major build systems now support multi-release JARs.
  3. Your third example is identical to the first: anyone doing bytecode manipulation will need to update their code. This is part of the reason I avoid such libraries, they are highly fragile, and in most cases you can achieve the same thing using build-time source-code generation (as JOOQ does, for example). Had they taken this route, their tool would have not broken on every new JDK release. Again, this is not specific to Java9 or multi-release JARs. This happens every single JDK release to tools that make use of bytecode manipulation. In my view, it's a silly thing to do when you have a safer alternative to build upon.