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

Steve Barham steve at ethx.net
Fri May 20 06:25:37 UTC 2022


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 on https://openjdk.java.net/projects/amber/ itself? 

Cheers,

steve (another hitherto silent lurker)


More information about the amber-dev mailing list