Preview APIs in the Java Platform

[Ty Young]

On 3/4/20 2:52 PM, Alex Buckley wrote:
> On 3/4/2020 12:10 PM, Ty Young wrote:
>>> Especially with Java 14, the entire Java developer community is 
>>> becoming aware of the high quality, carefully delivered nature of 
>>> preview features in Java SE. If we opened up the mechanism so that 
>>> API authors could use it, they would do so -- and each would make 
>>> slightly different commitments about quality and readiness. The 
>>> preview concept would soon find itself in the same place as the 
>>> semantic versioning concept: a simple "standard" for API authors to 
>>> follow in theory, but a widely abused and mis-applied concept in 
>>> practice. We are not going to take the risk of the preview concept 
>>> being diluted, because it's something that every Java developer 
>>> should recognize and understand when they peruse the latest "What's 
>>> new in Java XX" article.
>>
>> "slightly different commitments about quality and readiness" is 
>> exactly where you are now. String literals have been pulled and 
>> modified while other preview features have sailed by with no issues 
>> AFAIK.
>
> I have no idea what point is being made here. Raw String Literals (JEP 
> 326) were going to ship in JDK 12 as a preview feature, but we were 
> worried that they didn't meet the completeness bar set out in JEP 12, 
> so we didn't ship them in JDK 12. In contrast, Switch Expressions (JEP 
> 325) did meet the completeness bar, so we shipped them in JDK 12 as a 
> preview feature. We have the same commitment to quality and readiness 
> all day every day, which means some features make preview and some don't.


The point was that there was no concrete time frame from when a feature 
marked as preview would be delivered. There might be, as unlikely as it 
may be, that a feature goes through 4 different JDK versions before 
being released.


Which is in itself is fine, but you're arguing that these features can't 
be implemented because JDK developers somehow have some godly acute 
senses as to the readiness of a feature that third party developers 
somehow lacks. The fact that string literals had to be pulled, even if 
just once, proves this isn't the case(not that, I hope, any JDK 
developer would claim anyway).


and then making excuses as to why they won't be added based on 
hypotheticals pulled out of thin air when people are telling you point 
blank that they want these features. You've released the module system 
which was primarily made for the JDK and you've never cared about how a 
language feature like var would be abused, so why now?


>
> Alex