I'll put that in another thread so it gets the attention it needs, yet doesn't risk derailing consensus around Jakarta EE 9.
-- David Blevins 310-633-3852
On the call, we discussed a set of tests and spec documents that sounded like they were ready, or almost ready, but not voted on or released - so that potentially sounded like an item of work that may need to be done. Apologies if it's something that should be obvious, or its been answered before, but could someone point me a quick pointer at what we're looking at? I'm interested in getting a view on what's needed and how I could potentially help.
Thanks
Jon David, I'm assuming the
"our" in your description is referring to Tomitribe? Since
you are a lead on the Platform project, I just wanted to clarify that the
"our" does not refer to the Platform project. Thanks.
Overall, I like
your proposal, but I have a few questions/concerns...
Not dropping the
EJB Entity Bean support and the rest of the Optional Features of EJBs does
increase the amount of work required to move to the jakarta namespace.
(I believe one of Steve's replies on a separate thread is saying
the same thing.) There are spec updates, API updates, and lots of
TCK updates that will still be required -- even if these are marked optional.
As Bill as mentioned several times, marking something as optional
does not decrease the workload.
Your proposal
does not mention the pruning of Enterprise Web Services, JSR 109. This
was on the original list. Where does Tomitribe sit with this? Prune
it? Leave it? Mark it optional?
Moving Activation,
JAXB, and JAX-WS to respective EE4J projects, but leave them in the javax
namespace sounds like a viable alternative. This also has been discussed
on other threads, but it's not much different from just leaving them where
they exist as-is. The positive for this type of move is to just show
that they belong somewhere and are not abandoned. I would be okay
with this.
--------------------------------------------------- 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
From:
David
Blevins <dblevins@xxxxxxxxxxxxx> To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx> Date:
12/03/2019
03:07 Subject:
[EXTERNAL]
[jakartaee-platform-dev] Consolidated Proposal for Add/Remove Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Here's our perspective on the Add/Remove
votes in progress.
Prune the following specifications from the platform:
• Jakarta XML Registries JSR 93
• Jakarta XML RPC JSR 101
• Jakarta Deployment JSR 88
• Jakarta Management JSR 77 note this was not optional or deprecated in
Java EE 8 Add the following specifications to the platform (as javax or jakarta):
• Jakarta XML Binding
• Jakarta Activation
• Jakarta Web Services (JAX-WS) Move all the EJB specification to the jakarta package and make no further
changes in this release. The parts that are designated as optional
in EJB 3.2 such as Entity beans, would remain optional.
TL;DR
We are concerned that more change than this is overall too much for consumers
given the already scary namespace change.
ACTIVATION
This specification is a transitive dependency of several specifications
in Jakarta EE 9 such as JavaMail, EJB and JAX-RS. It will be in every
implementation of Jakarta EE 9 and no vote will actually remove it. A
vote to "not add" it would result in it being present, but without
TCK coverage.
We do not have a strong opinion on if it should stay in javax or migrate
to jakarta, only that it should be acknowledged and tested.
JAX-WS, JAXB
JAX-WS and JAXB (SOAP and XML) appear to be very widely used not just in
legacy apps but in new clean-room apps. We frequently see people
stand up new microservices that adapt third-party SOAP APIs for internal
systems and re-expose them as REST APIs.
JAX-WS and JAXB were officially part of three Java EE platforms (5, 6,
7) and officially part of three Java SE versions (6, 7, 8). It was
dropped by Java SE 11 and is now causing industry migration issues. We
see now is the time to strategically re-add it to Jakarta EE to alleviate
migration issues. Further, for it to not be in either Java SE or
Jakarta EE could be a worst case scenario for customers who might feel
abandoned by both Java SE and Jakarta EE at relatively the same time with
no standard migration path. We feel we would be lining ourselves
up to have Java 11 migration frustration redirected at Jakarta EE and our
reputation permanently damaged.
We do not have a strong opinion on if they should stay in javax or migrate
to jakarta, only that they should be included.
We would lean to them being included as javax as these specifications are
stable, not in need of evolution, but are widely used and fit for purpose.
It appears most of us will include these specifications as `javax`
in our platforms. Having them included at all is what users care
about, so it begs the question on what benefit we get drawing the line
that "included means a package change" as it would result in
us telling people they aren't included and then including them anyway.
We are likely creating FUD we don't need on top of an already tricky
transition.
Despite being strongly against Incremental in the past, even as recently
as last week, we would be supportive of including them now as `javax` and
adding them as `jakarta` in the future. It appears only Activation,
JAX-WS and JAXB have the potential to be incrementally developed. Changing
one would likely change them all, so it would not be drawn out and likely
not soon. We imagined far worse Incremental scenarios.
EJB REMOVALS
Should vendors wish to optionally support the Enterprise Bean functionality
that is proposed for pruning, the result would be they would be in a position
that this would mean a split package - some aspects moving to jakarta.ejb
and the pruned elements being available via javax.ejb. Both parts share
things like exceptions, so there would be issues around which package those
exception would reside under, and making migration more difficult for the
consumer. Given EJB wraps all exceptions by default and exceptions
can travel several stack levels, there would be no reliable way any compatibility
tool would know which originated from Session beans and which originated
from Entity beans.
We do not see a way to split and remove parts of EJB without creating considerable
frustration for users that would deter them from Jakarta EE 9 entirely.
It would also greatly increase the effort for vendors to still support
them while having no impact on vendors who are already allowed to not support
them as they are optional.
If "remove" meant all of EJB could be migrated to jakarta, but
only certain features included in Jakarta EE that could open up different
discussion. This would be not unlike CDI supporting several Java
SE features which are not officially part of Java EE/Jakarta EE.
-- David Blevins http://twitter.com/dblevins http://www.tomitribe.com 310-633-3852
_______________________________________________ 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
_______________________________________________
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
--
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|