So what if the necessary JAF change was done in a service release under the JCP and ported to some future Jakarta project release if needed?
Ah, ok, I see what I missed. This is quite a mess, isn't it.
If these other APIs are simply not part of the platform, then they
would only be included in products that need to support backwards
compatibility, and those products would need to handle aliasing
javax.activation to jakarta.activation.
David Blevins wrote on 12/4/19 4:05 PM:
I don't
understand this comment:
If
Jakarta Activation is voted to move to the jakarta
namespace, then these Specs can not be optional due to
the dependencies.
As far as I can tell, none of these specs have any API
dependencies on Activation, although it's used in the
implementation of some of them. Is there something I'm
missing? Why does the package name of Activation control
whether or not these can be optional?
Here's the bytecode analysis for Activation and how the
dominoes fall:
If there's anything incorrect or avoidable in there let's
definitely discuss. Always better to have more choices if we
possibly can.
-David
Kevin Sutter wrote on 12/4/19
3:33 PM:
Preamble: https://www.eclipse.org/lists/jakartaee-platform-dev/msg01180.html
Please vote +1/0/-1 on the following. Any
non +1 vote, please provide reasoning in your reply.
Thank you!
Mark Optional (Leave in javax namespace) -
Vote
• Jakarta XML Binding 2.3 JSR 222
• Jakarta XML Web Services 2.3 JSR 224
• Jakarta Web Services Metadata 2.1 JSR 181
• Jakarta SOAP with Attachments 1.4 JSR 67
You need to understand and vote on the
Jakarta Activation Vote 2 before voting here. If
Jakarta Activation is voted to move to the jakarta
namespace, then these Specs can not be optional due to
the dependencies. Check out this tool from Tomitribe:
https://www.tomitribe.com/jakarta/ns/poll/vote
These are four of the APIs that were recently
dropped from Java SE 11 per JEP 320 (another one was
Activation and that's the subject of a separate Vote
2). There was a lot of discussion about whether these
should be left out or added back in, and whether the
namespace should be updated or not. We are proposing
that we leave all four of these Specifications/APIs in
the javax namespace and clarify their usage as
Optional in the Jakarta EE 9 Platform. This should be
the minimal effort option to lower the bar for new
implementations.
Note: 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
|
