no problem.
On Fri, Jan 30, 2026 at 3:22 PM Ron Pressler <[email protected]> wrote: > > Oh, I apologise! > > > On 30 Jan 2026, at 22:20, Steffen Yount <[email protected]> wrote: > > > > For what it's worth, the recent "Java Language Enhancement: Disallow > > access to static members via object references" thread and suggestions > > there weren't mine. My first and otherwise most recent foray into > > engaging with you guys on this list was way back in late 2023. > > > > On Fri, Jan 30, 2026 at 1:05 PM Ron Pressler <[email protected]> > > wrote: > >> > >> 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
