New informational JEP: 14: The Tip & Tail Model of Library Development

[Alex Buckley]

On 10/18/2024 6:59 PM, Alan Snyder wrote:
> 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?

The JDK is all-in on tip & tail, so backporting new language features to 
old JDKs isn't going to happen. It's not just a matter of patching javac 
in JDK 8uXX: it's also the cost of revising the JLS, the JCK, 
documentation, etc, from the Java 8 release.

In addition, many recent language features need library and/or VM 
support. For example, the translation of text blocks from source code to 
bytecode is specified in terms of new methods in java.lang.String (see 
JLS 3.10.6), while the translation of patterns involves a new class file 
attribute and new methods in java.lang.invoke (search for "carrier 
runtime" in 
https://mail.openjdk.org/pipermail/amber-spec-experts/2023-March/003766.html). 
Now the cost of backporting spreads to Hotspot, the JVMS, and the 
javadoc. What if a new feature's supporting API in javadoc uses code 
snippets (JEP 413) or Markdown comments (JEP 467) that aren't support by 
javadoc from JDK 8?

Even when a language feature appears truly small and standalone, that's 
often just an artifact of how we're choosing to split up a larger 
feature for faster delivery in the tip train. You don't have to wait 
years for a big-bang release to get pattern matching because we've been 
delivering useful parts of the pattern story in every release. This 
means that most pattern matching JEPs, in addition to specifying their 
advertised feature, make deep cuts in the JLS and javac to prepare for 
future pattern matching JEPs, so it's not possible to pick and choose 
pattern features -- they all build on each other.

Alex

> Features that might have this property that I would find useful include
> 
> * flexible constructor bodies
> * local variable type inference
> * string templates
> * text blocks
> * unnamed variables
> * pattern matching for instanceof
> 
> 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.