| Re: [jakartaee-platform-dev] Jakarta 10.1? |
Hi,
In a similar vein to how we did Jakarta 9.1, what about doing a Jakarta 10.1 that only focuses on the security manager removal and JDK 17?
Jakarta 10.1 would then make sure that all TCKs are updated to not use the security manager in any way, and subsequently only JDK 17 is tested. Implementations certifying for Jakarta 10.1 are therefore guaranteed to run without a security manager and are also guaranteed to run at least on JDK 17.
During the EE 9.1 development, David reminded me that TCK tests
need to work on both eager/lazy class loading JVMs. In order to
pass on eager class loading JVMs, classes that reference the
Security Manager classes cannot be loaded or they will get a class
not found exception (CNFE).
I think we need to concentrate our effort on EE 11, otherwise we
won't complete the release in a timely manner. Also due to the
eager class loading JVMs which we would want to support I think,
the security manager needs to to be removed from the SPEC APIs
also (to avoid CNFE failures), which requires a major EE release I
think.
The work for Jakarta EE 11, which mainly takes place in the component specification projects, can largely or even entirely continue in parallel.
My preference is to start on EE 11 now and not delay starting the
work which includes a lot of TCK changes that need to happen
before we start any SPEC Ballots (we might be able to do some
parallel effort but once ballots start, TCKs that are used must be
completed).
Thoughts?
Thanks for starting this thread to discuss now! A lot of good
feedback!
Scott
Kind regards,Arjan Tijms
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev