On Fri, 29 May 2026 08:28:19 GMT, Eirik Bjørsnøs <[email protected]> wrote:
>>> Just wanted to chime in to say that if we plan to introduce some form of >>> modality in behavior, I wonder if it would be beneficial to try and avoid >>> having a system property control behavior which is otherwise not reachable >>> programmatically. >> >> See the notes above about next steps which will propose a new constructor >> and maybe deprecate the existing constructors. > >> See the notes above about next steps which will propose a new constructor >> and maybe deprecate the existing constructors. > > Yes, sure, I'm fine with those > > My concern was more about any system property and that they should be simple > switches which picks the default mode. They should not hold independent > semantics which needs to be documented in other terms than the modes > documented in the API. Any system property introduced now should account for > the modes/constructors we want to introduce later. They will co-exist for a > long time. > > Maybe this is just a given and my comment here is superfluous. My concern was > usability and future users having to understand two different ways of > controlling behavior and resolve any conflicts between them. > > I think I'm happy if we avoid introducing a system propery now which later > proves difficult to define in terms of behavior specified by the new > constructors / APIs . My understanding is that we only need the system property for JDK 27 and earlier releases. Once we come up with a real fix which will probably contain API changes which can't be backported, the system property wouldn't be required any more and deprecated/removed as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3323453661
