Making JavaMail optional is certainly something to consider, as a few other viable candidates especially JBatch. Or alternatively, expanding the pruning effort to include JavaMail. That is a rather isolated API that certainly can be included as an implementation feature that is run as a project outside of the platform.
You may be right.
We can always consider pruning them in some future Jakarta EE release, but putting them in a profile in the short term is probably the best way to satisfy the requirement to have them be part of Jakarta EE but not increase the size of the base Jakarta EE platform.
Steve Millidge (Payara) wrote on 12/5/19 10:03 AM: My feeling is we are being drawn inexorably to a moving of JAX-WS and JAX-B to Jakarta namespace (whether optional or not) and therefore likely a base of Java SE 11. Yes, in Jakarta EE 9.
I've been waiting for us to get deeper into these discussions so that it's worth diving into the details, but...
Activation depends on the java.awt.datatransfer package. That made sense at the time, pre-Swing, when Java on the desktop was still very interesting. Unfortunately, Android doesn't include java.awt.datatransfer, so using Mail, which depends on Activation, requires some sort of kludge to work around or supply the missing package.
I'd like to remove the dependency on java.awt.datatransfer in Activation so that the same version of Mail can be used on both Java and Android. This is an incompatible change, although not one that is likely to impact any users of Mail (the biggest user of Activation) or JAXB or any of the other minor uses of Activation.
So, since Jakarta EE 9 is already a BIG incompatible change, I'd like to add this small incompatible change to the list. After Jakarta EE 9, I don't think we want to be introducing more incompatible changes (although we haven't yet had the discussion to decide on rules for such things), so it seems to me that I have one window to fix this problem.
(Note that there's a few other similar issues we'll need to deal with in Jakarta EE 9, such as the removal of java.security.Identity and the impact on the EJB API. Clearly Jakarta EE 9 is not going to be only package renaming.)
|
