Initial discussion of solutions for issues presented in amber-dev/2022-May/007322

[Brian Goetz]

I think the most useful thing the community can do to help is: exactly 
what you just did. (Thank you!)  There are ~10M Java developers, and 
each of them probably have a language feature idea in their pocket.  We 
can't fault them for their optimism, but 99% of these ideas are 
unrealistic or ill-formed, and the rest are just way^3 more work and 
complexity than they imagine.

The only way this works is if the folks who have spend more time in the 
community step up, like you have, and share what they've learned from 
their hitherto silent lurking, rather than having it fall to the ones 
who are also tasked with doing the actual work of stewarding, refining, 
and implementing platform evolution choices.  (Evolving a platform like 
Java requires a holistic view across not only the entire platform, 
history of computing, and all the other programming languages out there, 
but of the many possible but mutually incompatible potential futures for 
Java as well; this is not a very scalable activity, so taking load off 
of us is multiplied manyfold.)

As to "would it be worth collating feature ideas" -- maybe :) Being able 
to reach into the list archive and pull up a relevant item is hugely 
valuable; there's gold in there, and its largely unindexed.  But we've 
also had some bad experiences along this front.  In the early days of 
Java, the Java bug database had an RFE issue type, and eventually it 
became nearly a full-time job sifting through, responding to, and 
cataloging them.  Eventually it became clear that the arrival rate for 
RFEs overwhelmed any realistic ability to evolve the language -- even 
back then when there were fewer constraints.  There was a voting 
mechanism, by which people could upvote their favorite, but there were 
so many items that there was a huge reinforcing effect where people only 
looked at the top 50 of 5000, and upvoted their favorite of those.  (For 
a decade, the top item was "Design by Contract".)

Having a list of "maybe but not yet" features can also generate a lot of 
noise.  People invariably see such lists as promises. (The number of 
times when people ask "why didn't feature X make version Y", when there 
was never any plan for it to make version Y, is staggering.  Many people 
see a list of future features and implicitly assume they're coming in 
the next version, and feel lied to when it doesn't happen.)  They also 
see such lists as handholds for arguing, either for an alternate version 
of the feature design (a big distraction), or lobbying for priority (a 
smaller, but often more annoying distraction, because it's even more 
subjective.)

So I encourage the community to think about how to self-organize to 
support us in moving the language forward.  More Steves would definitely 
help!


On 5/20/2022 2:25 AM, Steve Barham wrote:
> Hi Julian,
>
>> Yes, it is true that this seems to just be a minor inconvenience at first,
>> but the real issue is when you have to scale such code to bigger
>> applications. Writing public static methods and fields over and over again
>> is not a very fun thing to do, for instance.
> Proposing a change to the language, compiler and VM because you have a dislike of writing ‘static’ does not feel appropriate (or likely!) to me. With respect, you are approaching this problem from a very narrow angle - you stated what you would like originally, and then increased the word count in your second email.
>
> I’d encourage you to review some of the past discussions on this list and on amber-spec-experts. Brian mentioned changes to nesting rules;https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001904.html  might be a good start point, but I seem to recall more discussion outside of this thread, so keep reading ahead in time!
>
> As a more general topic - I’ve noticed that there’s been an uptick in social media discussion of Java, which I’d attribute to larger projects like Valhalla, Panama and Loom reaching public consciousness, as well as recognition of the QoL enjoyed in current Java. This may lead to more threads like this one arriving - or like the recent nullability thread, where bright eyed enthusiasm for ‘simple’ changes meets the reality of architecting a language for the next 25 years. Good problem to have, but probably somewhat time consuming to respond to.
>
> Would it be sensible to collate ‘won’t do’ or ‘won’t do - yet!’ information in some form - perhaps onhttps://openjdk.java.net/projects/amber/  itself?
>
> Cheers,
>
> steve (another hitherto silent lurker)