P.S. Your previous suggestion about turning some warning into an error suffered the same flaw. All it said was that the pattern is potentially confusing. But that’s why there’s a warning. That’s not how to motivate turning a warning into an error. What is the problem with the warning? Is it that your team don’t turn it on? Do you turn it on but ignore it? Why is it that particular warning that merits becoming an error? Are the problems caused by it particularly serious?
Without clearly stating what the problem you wish to solve is, it’s hard to judge the merit of any solution. If you look at our JEPs, they start with a motivation section. That’s the first step: clearly identify a problem and explain why it’s an important one for the platform to solve. It’s very important for us to know what problems people encounter, and we appreciate such reports, but if you don’t tell us exactly what the problem is we can’t help. — Ron > On 30 Jan 2026, at 20:34, Ron Pressler <[email protected]> wrote: > > > >> On 30 Jan 2026, at 19:58, Steffen Yount <[email protected]> wrote: >> >> Hi Ron, >> >> The problem I encounter—every time there is a planning meeting for a >> new service deployment—is the increasing preference for non-Java >> toolchains like Rust, Go, and even TypeScript. > > > Note that, with the possible exception of TypeScript, the languages you > mentioned are far less popular than Java today, and show no sign of closing > the gap. I’m certainly not saying they should be ignored, and we obviously > keep abreast of developments in the programming language space, but adopting > a feature cannot be justfied *just* because a far less successful language > has it. > >> >> The acute ceremony I described with ServiceLoader is merely a symptom. > > Okay, but since that is the symptom you’ve chosen to focus on, can you please > describe it? Maybe it can be addressed on its own, and maybe as part of a > larger change that can cure multiple symptoms, but first we need to know what > it is. > > The reason saying “ceremony” isn’t enough is this: Suppose some operation in > Java takes 20 lines instead of 2. If this operation is done once every 10K > lines, then this 10x improvement would amount to a 0.2% benefit, while still > incurring the cost of complicating the language. > > Such a vague description simply isn’t actionable, and to improve things we > need actionable information. > >> It remains a library-level escape hatch for a problem—polymorphic >> static dispatch and retroactive extension—that the language currently >> cannot express natively. > > > Instead of talking in the abstract about a missing mechanism, can you please > detail the specific problem you’ve encountered and are suggesting we should > solve, in a way that will allow us to determine how serious of a problem this > is compared to other problems we need to solve? > >> Without these facilities, Java remains >> "corralled" in an instance-based model while the industry moves toward >> the zero-cost, static-binding models of our competitors. > > > I don’t know what “an instance-based model” is and Java’s ability to make > some operations zero-cost matches or exceeds most of our competitors already. > Obviously, there’s plenty of room for improvement, but talking in such an > abstract way doesn’t help us improve anything. > > If you want to help us improve Java, show us the code you have to write > today, and explain why it’s problematic and why it’s an important problem to > prioritise. As Brian Goetz says, “tell us something we don’t know”. We know > what features TypeScript and Go and Zig and Julia and Elixir and Rust and ATS > and Python and C++ and Nim have. We don’t know what problem *you* ran into > and believe is serious enough for the platform to solve. > > — Ron
