Java 17 preview language level use

[Alex Buckley]

Hi Tagir,

Thanks for collecting and sharing this information about preview feature 
opt-in.

On 12/1/2023 1:57 AM, Tagir Valeev wrote:
> According to the stats that JetBrains gathers from the users (who agreed 
> to send anonymous statistics), now at the end of 2023, about 1.1–1.2% of 
> Java users still use Java 17-preview language level in at least one 
> module of their projects.

To be clear, does "use Java 17-preview language level" mean:

"They ticked a box to enable the use of 17's preview language features, 
but we don't know if they actually use pattern matching in switch in 
their code"  (Pattern matching in switch was the only preview language 
feature in 17)

or

"They ticked the box and wrote at least one pattern-matching switch in 
their code"

?

> Among users who are at Java 17, the percentage 
> is even higher, about 3.0–3.5%. This is more than 10x higher, compared 
> to use of preview level of Java 18, 19, 20, or 21.

I am surprised that users on Java 17 have a 10x higher opt-in to preview 
features than users on Java 18-21. Among other things, Java 19 and 20 
previewed virtual threads while Java 21 previews string templates and 
unnamed classes. Given the enormous interest in these features, I would 
have expected much higher preview opt-in _after_ 17 than in 17.

(Again, the only preview feature in 17 was pattern matching in switch -- 
a nice feature to be sure, but frankly a sidebar for people migrating 
from 8/11, because so much good stuff appeared between 11 and 17.)

> As we know, it's a little bit too late to use it to evaluate and submit 
> feedback, which is a primary purpose of the preview version. And we get 
> quite angry feedback from the users because we stopped supporting Java 
> 17-preview in our IDEs. So people really use preview features of LTS 
> Java versions in production.

We have already come (somewhat reluctantly, at least in my case) to the 
conclusion that people use preview features of _any_ Java version in 
production. We know this because widely distributed libraries that ran 
on Java 19/20 either used or supported the use of preview APIs like FFM.

> Probably, skipping preview features in LTS versions would be better. At 
> least, something to think about.

I know what you mean, but in both principle and practice it's not 
possible. First, in principle: LTS is not an OpenJDK concept, so it's 
not something a feature owner in OpenJDK has any way to consider. 
Second, in practice: even if you said "Look, everyone knows Java 25 is 
the next release after 21 to get long-term updates from vendors, so 
please avoid having preview features in 25", then you're basically 
saying that preview features have to be squeezed into the 22 and 23 
releases, so that they all have a high chance of finalizing in 24 or 25.

This focus on special "preview-capable" releases goes against everything 
the time-driven "train" model stands for. It would mean that a feature 
owner who's ready to preview in 24 would be told "Sorry, you've missed 
the preview train, come back in a year's time to catch it in 26." This 
would frustrate feature owners (who thought they were free of schedule 
games) and confound users.

There are also extreme practical difficulties if a feature previews in 
"non-LTS" releases but isn't quite ready to go final in time for your 
"LTS" release. Do you physically pull the feature out of the "LTS" 
codebase, or do you do the work to guarantee that preview features in 
the language, VM, and API are completely unusable in this release? The 
complexity is totally unwarranted.

Alex