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

[Alan Snyder]

I appreciate the emphasis in this JEP on minimizing the burden of
backporting changes.

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.

Value types are tempting, primarily as they impact library APIs, but I will
probably try to resist using them as long as I can.

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20241018/ad84f38c/attachment.htm>