User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
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.)
Please
vote +1/0/-1 on the following. Any non +1 vote, please
provide reasoning in your reply. Thank you!
Required
(leave in javax namespace) - Vote •
Jakarta Activation 1.2
Jakarta Activation was one of the APIs dropped from Java
SE 11 per JEP 320. Several Jakarta EE technologies
require the use of Jakarta Activation, so we can't make
it optional. It is required for Jakarta EE. This vote
is for whether we move this feature to the jakarta
namespace (-1) or leave it in the javax namespace (+1).
The recommendation is to Jakarta Activation in the javax
namespace. And, if at some later date, this API needs
to evolve and move to the jakarta namespace, then we can
deal with the ripple effect on other specs at that time.
Note:
A -1 vote indicates that you want Jakarta
Activation to be migrated to the jakarta namespace.
And, if we do that, then there is a ripple effect that
will also require corresponding changes to jaxb, jax-ws,
and soap. Thus, a -1 vote here means that Vote 3 on the
other Optional specs won't apply. That is, voting -1
here and +1 on Vote 3 doesn't make any sense. Check out
this tool from Tomitribe: https://www.tomitribe.com/jakarta/ns/poll/vote
Note2:
This assumes that all of the existing Specification
PRs for these technologies are properly brought under
the EE4J umbrella. We discussed these at the Spec
Committee call today and we are well aware that we need
to move on these and get them approved. • https://github.com/jakartaee/specifications/pulls?q=is%3Apr+is%3Aopen+label%3Ajavase
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
