Please stop incrementing the classfile version number when there are no format changes

[Brian Goetz]

> I'd like to propose these incremental changes.

You have an impressive ability to present radical suggestions as “small incremental changes” :)  

> Then I'll respond to the
> various objections made so far:

I think you have misunderstood the nature of the conversation.  These were not offered as “here are the list of objections you must overcome”; they were offered in the cooperative spirit of “you don’t seem to fully grasp the complexity of the problem, let us give you a handful of examples so you can see why it’s more complicated than you initially thought.”  These are not concrete objections, nor are they an exhaustive list; they were meant to be educational, not an invitation for a point-by-point argument.  

>   2. Make javac emit bytecode with the lowest possible class version for
>   what it contains, not the current target version.

This has been asked for and rejected a zillion times.  Among other reasons (I guess I have to say that every time), it is very confusing for users, when some features can be targeted back to preview versions and some not, and you only find out when compilation fails.  Which in turn, would surely lead to calls for “can we have an alternate back end so that (say) code that uses lambdas but is  targeted at older JDKs generates inner classes instead.”  Plus it asks every Java developer to keep a mental database about which (combinations of) features can be pushed back in time how far.  And many other reasons.  No thanks!  

>   3. Make javac default to a target version of N-1 (or the previous LTS),
>   thus requiring developers to opt-in if they want to use features that
>   depend on new bytecode features.

This is, essentially, the preview mechanism with a renumbering.  Are you proposing to basically make all features that depend on class file changes preview features until the next LTS?  That basically sets us back to where we were with the old cadence, that users had to wait years for new features, even though they are already ready.  Again, this is asking the 100% of Java developers to pay for something that benefits the .0001%.  Bad trade.  

> These changes are so small

This is an impressively misguided characterization.