Re: [jakarta.ee-wg] [jakarta.ee-spec] : Defining Jakarta EE 12 Scope in

[Emily Jiang <EMIJIANG@xxxxxxxxxx>]

Hi Brian,

I think the break changes assoicated with the removal of SM is only true if the SM is on any API signature. I don't believe this was a case. I think the usage of SM is pretty much on the method body. It is absolutely fine to remove the lines of using SM. I think it was the case for the specs who have SM removed in EE 11.

Thanks

Emily
================
Emily Jiang

Java Champion, Fellow of BCS

STSM, Jakarta and MicroProfile Architect @IBM

Liberty Cloud Native Architect & Advocate

E-mail: emijiang@xxxxxxxxxx
Twitter: @emilyfhjiang

LinkedIn: https://www.linkedin.com/in/emilyfhjiang/

---

From: jakarta.ee-wg <jakarta.ee-wg-bounces@xxxxxxxxxxx> on behalf of Brian Stansberry via jakarta.ee-wg <jakarta.ee-wg@xxxxxxxxxxx>
Sent: 14 January 2025 15:49
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Brian Stansberry <brian.stansberry@xxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>; Jakarta EE Working Group <jakarta.ee-wg@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-wg] [jakarta.ee-spec] [External] : Defining Jakarta EE 12 Scope in Program Plan

 

It's definitely important to discuss. It's a bit complex. Any spec project that removes the SM calls from their API jars is making a breaking change, so they need to update their version accordingly. I believe by releasing a new major

It's definitely important to discuss. It's a bit complex.

Any spec project that removes the SM calls from their API jars is making a breaking change, so they need to update their version accordingly. I believe by releasing a new major version. If an application that called into that spec API could run with the SM enabled, and then they update the spec API artifact and they get SM failures, that is a breaking change.

AFAIK, there are no plans to break the ability to call the SM APIs in SE 25, beyond a change to java.security.Policy.setPolicy where it now fails if invoked. Other than that JEP 486 doesn't remove the SM-related APIs typically used by libraries or cause them to fail. They just no longer do any enforcement. Since the user can no longer even enable the SM, there is no enforcement to be done. The upshot of this is a library that wanted from the same binary to support both SE 25 with no SM support and SE 21 with SM support could do so. Removing the internal SM calls means they need to maintain a new branch.

However, it is clear Java SE wants the broader Java ecosystem to move on from the SM, and personally my bet (based on ZERO information) is that the APIs will be gone by SE 29. So specs are well served by getting on with removing their SM code.

Further, I think it's a great thing for EE how recently it has been possible to certify an EE impl on an SE version that was not around when the EE version came out. WildFly was able to certify as EE 10 compatible on SE 21. I think it would be great if EE 12 impls could certify on SE 29. But if the SM API are removed in SE 29 and a spec API hasn't removed their calls, that is not possible. At least not without someone forking the spec API and producing their own artifacdt.

Then there are other situations like we saw with Connector where the spec itself has language that assumes SM support. That clearly needs updating.

On Tue, Jan 14, 2025 at 8:59 AM Reza Rahman via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:

OK. So, it sounds like Will is absolutely right in re-surfacing this conversation for EE 12.

On 1/14/2025 9:15 AM, Arjan Tijms wrote:

Hi,

It was platform wide, but not done comprehensively. Some teams forgot about it, and then refused to do it for Jakarta EE 11 still (using a service release). The reason for refusal was almost always that they didn't see value in removing the security manager for Jakarta EE 11.

See e.g. https://github.com/jakartaee/cdi/issues/831

Kind regards,

Arjan Tijms

On Mon, 13 Jan 2025 at 22:58, Reza Rahman via jakarta.ee-wg <jakarta.ee-wg@xxxxxxxxxxx> wrote:

Ed,

Do you know to what extent the Security Manager dependency removal work was done in EE 11? I know at least some work was done, but was it really platform wide, comprehensive, and consistent across specifications?

Thanks,

Reza

On 1/13/2025 4:50 PM, Will Lyons wrote:

All –

 

I don’t know if this topic has been covered so capturing it here.

 

If Jakarta EE 12 will be supported on Java 21 and Java 25, we will need to review the implications of features that are likely to be removed, including the following:

JEP 486: Permanently Disable the Security Manager

https://openjdk.org/jeps/486

https://inside.java/2024/12/11/quality-heads-up/

 

My understanding is that some Jakarta EE specifications have a dependency on Java Security Manager, especially Connector.   The implications of this removal, and the alternative actions in response, should be identified.

 

Thanks

 

Will

 

From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> on behalf of Reza Rahman via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Date: Tuesday, October 22, 2024 at 5:31 AM
To: jakarta.ee-spec@xxxxxxxxxxx <jakarta.ee-spec@xxxxxxxxxxx>, jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Reza Rahman <reza_rahman@xxxxxxxx>, jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>, JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: [External] : [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan

Hi folks,

I would like to see if we can define clear, compelling, and specific
scope for Jakarta EE 12 as part of the Steering Committee Program Plan:
https://urldefense.com/v3/__https://docs.google.com/presentation/d/1xUNDHMP_qTHH1wA3m0yCmWVf_sHp41Qd7Opq3FhgINs/edit?usp=sharing__;!!ACWV5N9M2RV99hQ!JRyWXHKEIqZVVomnYLlS0QyUtsJEoWg8IRbVnLEaSORXIZEDGC7g2LKdj0UEv5FUv236NQVnUAlM3c_VR54pIbg1yb5z$ .
I believe this is of critical importance at this juncture. If I did not
think so, I would not bother trying. I have detailed all the rationale
here:
https://urldefense.com/v3/__https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing__;!!ACWV5N9M2RV99hQ!JRyWXHKEIqZVVomnYLlS0QyUtsJEoWg8IRbVnLEaSORXIZEDGC7g2LKdj0UEv5FUv236NQVnUAlM3c_VR54pIW1VfRhW$ .
For those that recall, something very similar was done for Jakarta EE
11, so this isn't exactly without precedent.

I would like to see if this can be done in the following couple of
weeks, when the Program Plan is due.

Thanks,

Reza

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!JRyWXHKEIqZVVomnYLlS0QyUtsJEoWg8IRbVnLEaSORXIZEDGC7g2LKdj0UEv5FUv236NQVnUAlM3c_VR54pIbNA_FIw$

_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

WildFly Project Lead

He/Him/His

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN