What exactly wasn't said very well?
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.
This scenario is not isolated to the CDI implementation, nor other Jakarta Specification implementations. It applies to nearly all Java libraries that have ever wanted to be used in a JVM instance where a security manager can be present (and still true even
in Java 18). I've been through this kind of thing also; you don't have to search up old responses just for fun to educate the rest of us.
The whole point of my comment was an attempt to illustrate what it will take to prepare for doPrivileged to really go away. I'm not trying to ignore this issue at all. On the contrary, while we do prepare, I think the Jakarta community as well as others we
are involved in should voice our concern that nearly all libraries our stack is developed on will need to recompile to handle the removal of this very widely used method on AccessController. While we may be able to control everything, we maintain directly
I doubt our customers and users will have the same luxury. All of that because the JVM wants to get rid of a method that will eventually become a no-op method. This will become another horrible inflection point for Java.
Tom
From: cdi-dev <cdi-dev-bounces@xxxxxxxxxxx> on behalf of arjan tijms <arjan.tijms@xxxxxxxxx>
Sent: Monday, February 28, 2022 12:03 PM
To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cdi-dev] Weld 5 CR release is now available
Hi,
Well, I personally think it wasn't said very well, and that we should talk about it now, or even should have talked about it more last year already.
I went through the 8 bit to 16 bit time, 16 to 32, 32 to 64, through the Applet deprecation and removal, and the module introduction etc. Every time people didn't believe that such a transition would be upcoming, or ignored it. Then, almost without exception,
people were surprised when the transition did happen, overwhelmed by the amount of work, and customers angry that the transition took so much time because nobody ever prepared for it in advance.
A while back I found an ancient note where I warned about not using upper bits for a custom purpose because a transition to 32 pointers was coming soon. The reply I got then was almost identical to the replies here now. Just for fun, I'll try to find it
and post it again (on Twitter or so, as I think everything has been said here).
Kind regards,
Arjan
Very well said, Tom!
I also think we should talk about SecurityManager in the future when the roadmap for removing SecurityManager is clear. The removal might not happen :o. So far, it is up to the project implementations to do whatever they feel makes sense.
Thanks
Emily
I have heard discussions about removing security manager integration from the EE specifications. That is something I think is a great idea even before the talk to remove the SecurityManager from Java, just not being done for EE 10.
Regardless, I'm not sure why a discussion about a bug fix in a compatible implementation is the focus here. That is up to the discretion of the implementation project.
As a broader Java community, I am not looking forward to when Java removes AccessController::doPrivileged altogether. The JEP says:
<quote>
In Java 18 and later, we will degrade other Security Manager APIs so that they remain in place but with limited or no functionality. For example, we may revise AccessController::doPrivileged simply to run the given action, or revise System::getSecurityManager
always to return null. This will allow libraries that support the Security Manager and were compiled against previous Java releases to continue to work without change or even recompilation. We expect to remove the APIs once the compatibility risk of doing
so declines to an acceptable level.
</quote>
To be honest, I cannot predict how long it will take for the compatibility risk to decline to an acceptable level. But it will trigger millions upon millions of lines of code to have to change simply so the JVM can remove a no-op doPrivileged method. I sure
hope that win is worth it to the whole Java community.
Tom
Hi,
I know, but isn't that just delaying the inevitable? I mean, with some tricks you can still run applets today (sorry for coming up with applets all the time), but it doesn't mean one should, or that anyone should seriously support this.
All I'm really saying is that we had a ton of issues with crossing the JDK 8 to JDK 11 barrier, since despite that we all knew modules were coming, almost nobody prepared.
Now we know the security manager is going to disappear. So shouldn't we prepare for it, so that by the time it's really gone, we won't need half a decade or more to get our users passed JDK 17?
Kind regards,
Arjan
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
--
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
|