We already committed to not doing any more JCP releases of these
APIs.
Scott Stark wrote on 12/4/19 7:28 PM:
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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
