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

[Joseph D. Darcy]

On 10/23/2024 8:16 AM, Maurizio Cimadamore wrote:
>
> On 23/10/2024 15:56, Alan Snyder wrote:
>> It seems that you have set up a straw man [1] here and used it to 
>> predict doom.
> Uhm not sure I did that :-)
>>
>> I did not suggest targeting features that affect the Java data model 
>> like sealed classes, records, and pattern matching to older JDKs for 
>> exactly the reasons you mention.
>> My suggestion was intended to apply to convenience features like new 
>> syntax for string literals and improved type inference, which can be 
>> defined in terms of source to source translation.
>
> So you agree with me that what you propose will amount to cherry pick 
> features.
>
> And, since features are more often than not, inter-related, it is not 
> clear to me how you draw that line. I mean, I see the line that you so 
> badly want to draw - what I'm trying to say is: that line doesn't 
> really exist (or is not nearly as widely applicable as you think it is).
>
>>
>> Flexible constructor bodies is a more challenging topic, and I don’t 
>> claim to know what the implications are. The motivation would be to 
>> untangle the complexity in my current code to work around the current 
>> strict requirements. The code examples you give are all changes to 
>> the compiler (and test programs), which don’t tell me anything about 
>> the impact on the runtime environment. Performing the required 
>> extensive testing on Frankenstein Java might not be that hard, if the 
>> test programs do not use other recent language features or can be 
>> altered to avoid them.
>
> Again, you are not really arguing against what I said - you are saying 
> that it will be _somebody else's job_ to do the required amount of 
> testing required to make sure that you can happily use flexible 
> constructor bodies in Java 8. The key question is: whose job? If the 
> job falls on the same group of developers who is also trying to move 
> Java forward, don't you see an issue? In the end, like many other 
> things, it's a matter of deciding how to allocate a (finite) amount of 
> resources at our disposal to the things in our radar.


To reiterate Maurizio's points, a task being technically feasible -- 
such as selective backporting of new language features to old releases 
-- is a necessary but not sufficient condition for it to be considered 
for the JDK. As always, there is a balance between stability and 
progress in maintaining the platform, and creating chimeric hybrids of 
language features grafted onto old releases doesn't have favorable cost 
vs benefit trade-offs. We want to use and do use new language features 
in implementing the JDK and its regression tests and it is an 
unreasonable constraint to limit the language features used in the JDK 
in 2024 to, say, the language features that were first shipped in 2014 
with JDK 8.

Since JDK 9 with the introduction of the --release N option to javac, it 
is easier to think of the source level, class file target version, and 
platform libraries as three inter-related properties that evolve in 
lockstep. (At a first approximation, --release OLD_VERSION is equivalent 
to "-source OLD_VERSION -target OLD_VERSION --bootclasspath 
OLD_PLATFORM_LIBRARIES.jar".)

-Joe