<div dir="ltr">I appreciate the emphasis in this JEP on minimizing the burden of backporting changes.<br><br>However, for me, maintaining multiple releases is also burdensome. For that reason, I target library development to JDK 8 and probably will continue to do so as long as JDK 8 is relevant. I understand that there are disadvantages to not being able to use newer language features, but so far, the disadvantages of maintaining multiple releases outweigh the advantages of the new language features.<br><br>Value types are tempting, primarily as they impact library APIs, but I will probably try to resist using them as long as I can.<br><br>I have a suggestion that might be helpful to me and others in the same boat. Are there language features that do not impact the byte code and do not require runtime support? If so, would it be possible to support those features (using a compiler flag) when targeting older releases like JDK 8?<br><br>Features that might have this property that I would find useful include<br><br>* flexible constructor bodies<br><br>* local variable type inference<br><br>* string templates<br><br>* text blocks<br><br>* unnamed variables<br><br>* pattern matching for instanceof<br><br>Something that might be useful in the future is support for multi-release class files. That might allow some language features that impact byte code to be supported on older JDKs. I’m thinking specifically of value types. If value types could have run as ordinary classes in older JDKs that would be Nirvana.<br><div><br></div></div>