What exactly wasn't said very well?
Well, it's not that the entire thing wasn't well said, but more like the "That is up to the discretion of the implementation project." from which the response was "I also think we should talk about SecurityManager in the future".
That's about the exact opposite of what I was saying. I was arguing for a platform wide approach here (just starting with CDI here, as it happened to come up) and definitely not talk about it in the future, but talk about it now.
So from my point of view, "discretion of implementation" and "future" are not a good idea. Of course I may be wrong, and then it would be well said. Perceptions obviously matter here.
Let me try this again.
1) Jakarta EE 10 has specified the behavior for when a security manager is present.
2) Jakarta EE 10 allows implementations to support Java 11 and higher.
3) Java 11 through Java 17 (and even into the latest Java 18) all allow a security manager to be set. Albeit some versions require an extra option to be set.
4) Jakarta EE 10 implementations that want to behave properly when a security manager is present will likely have to make use of the doPrivileged method.
Maybe I'm getting too old, and am suffering from the burden of having seen all of this before. Essentially all those points were made in the same way when we transitioned from 16 bit to 32 bit. There too, we had options and settings and even compatibility stubs to still allow misbehaving 16 bit code to run to some degree on 32 bit environments. The existence of these very options then too was used as an argument to not prepare.
This will become another horrible inflection point for Java.
For code that wants to be "cleanly" compatible with JDK 18 (not asking the users to apply settings), it kinda already is.
But I do understand your point of view too. It's not a black/white situation and not every code base has the luxury to prepare early.
Kind regards,
Arjan Tijms
