Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Consolidated Proposal for Add/Remove

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
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852

On Dec 3, 2019, at 10:31 AM, Jonathan Gallimore <jgallimore@xxxxxxxxxxxxx> wrote:

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

On Tue, Dec 3, 2019 at 2:13 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
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


--
Jonathan Gallimore
_______________________________________________
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


Back to the top