| Re: [cdi-dev] Weld 5 CR release is now available |
|
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
On Mon, Feb 28, 2022 at 1:56 PM Emily Jiang via cdi-dev <cdi-dev@xxxxxxxxxxx> wrote:
|