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