Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] VOTE: Specifications to add inJakartaEE 9
Hi,

I think it's worth to clarify whether the intention of the proposals is to "remove" or "add/not add" JAX-WS, JAXB and other Java SE APIs that were dropped from Java 11.

I strongly believe that JAX-WS and JAX-B should be considered required for Java EE 8 and thus they should rather be considered for removal or keeping in Jakarta EE 9. Just not adding them would create confusion and unexpected backwards-incompatible changes.

I'm not going to express my opinion about whether to have JAX-WS and/or JAXB in Jakarta EE 9. I'm not a committer and I'll leave the vote to others. But I suggest to change the 2 votes about pruning and adding APIs so that JAX-WS and JAXB are considered for removal rather than considered to be added. If they are not voted to be removed/deprecated they should "stay" in Jakarta EE 9.

Here's a quote from the Java EE 8 Platform spec document that explains why I think that Java EE 8 requires JAX-WS and JAXB and not that it's just provided by Java SE 8. It states that at least Java SE 8 APIs should be provided. The wording is not explicit but I believe that the most natural way to interpret the term "enterprise technologies" in Java SE is that they are required by Java EE 8 even if they don't exist in Java SE. And that's why I believe Jakarta EE 9 should either clearly state that JAX-WS and/or JAXB are no longer required or it should include them among Required Java Technologies in section EE 6.1.2

EE.6.1 Required APIs
EE.6.1.1 Java Compatible APIs
The containers provide all application components with at least the Java Platform, Standard Edition, v8 (Java SE) APIs. Containers may provide newer versions of the Java SE platform, provided they meet all the Java EE platform requirements. The Java SE platform includes the following enterprise technologies:
• Java IDL
• JDBC
• RMI-IIOP
• JNDI
• JAXP
• StAX
• JAAS
• JMX
• JAX-WS
• JAXB
• JAF
• SAAJ
• Common Annotations

All the best,
Ondro

št 28. 11. 2019 o 16:44 kzr@xxxxxxxxxxx <kzr@xxxxxxxxxxx> napísal(a):

If we don’t do anything for JAXB, the customer might be confused.

Some vendors provide JAXB in their products, and they claim their products are compatible with Jakarta EE 9.

Other vendors do not provide JAXB in their products, and they also can claim their products are compatible with Jakarta EE 9.

These products are all Jakarta EE 9 compatible, but there are less compatibilities among vendors’ products

than what we were doing with Java SE and Java EE.

 

-Kenji Kazumura

 

 

From: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] On Behalf Of Kevin Sutter
Sent: Thursday, November 28, 2019 11:58 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] VOTE: Specifications to add inJakartaEE 9

 

Nobody is proposing to *remove* JAXB from Jakarta EE.  Nobody is proposing to *remove* JAXB from Java SE.  If we don't do anything and leave JAXB as it is today, nothing changes.  Nothing.

JAXB is no longer delivered with Java SE 11 and beyond.  But, this is not a big problem.  All of the Application Servers that have claimed support for Java SE 11 have already figured this out.  It's not rocket science.

Werner's question on whether "Tomitribe plans to support JAXB?" isn't that far-fetched.  If JAXB is moved to Jakarta, somebody or some team will have to step up to own the Specification Project for JAXB.  And, maybe that's how we should play this out...  Leave JAXB off the list for Jakarta until somebody or some team steps up to driving and owning this effort.  I know the Lukas has started this activity, but I'm not sure if this a long-term commitment or not...  https://projects.eclipse.org/projects/ee4j.jaxb

---------------------------------------------------
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:        Amelia Eiras <aeiras@xxxxxxxxxxxxx>
To:        jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>, erik.brangs@xxxxxx
Date:        11/27/2019 13:53
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] VOTE: Specifications to add        inJakartaEE 9
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx




+1 Erik and quote you:

 I think that not providing technologies that were available in Java EE 8 (even if they came from Java SE) is very risky for the future of the project because it runs contrary to the expectations of backwards compatibility that might exist. In my opinion, backwards compatibility is essential and in the special case of Jakarta EE it is not only about what's actually in the specs but also about the perception of changes by the community.

Stated on another thread [linked below] , it seems that the current work being done in Jakarta EE 9 release is not considering carefully the pros & cons. At this time, we don't have the actual data from users, as an ecosystem,  to sustain current desires of what effectively cut or not.  Being patient while doing the work now seems the wisest step forward instead of graving into a whole that cannot be fixed later, Trust is lost via small actions & rarely lost with just 1 action itself. I am wary of what currently is.  I am considering not only the coders but the users as both are core and important for this project's success.   

Current methods are pushing on the side of radical steps, that is a red flag in itself for users. Are we really choosing to become that ecosystem? 

Erik, you are one great example of  a Jakartee whose arguments are impossible to ignore.  

-- The power-of-preparation, POP, from this community cannot be underestimated or deferred. We have now. 
The project requires individuals whose arguments are hard to ignore or push around, those who makes us understand our weakness are the most valuable contributors. -- Nov 26th forum Community thread

Amelia Eiras 
twitter.com/ameliaeiras
Tribe: http://tomitribe.com      https://tribestream.io   
OSS:  http://microprofile.io     https://jakarta.ee


On Wed, Nov 27, 2019 at 11:32 AM Erik Brangs <erik.brangs@xxxxxx> wrote:

Hi,

On 27.11.2019 19:21, Werner Keil wrote:
> Well it breaks as soon as they run their Java EE 8 compliant app or container in a JDK above Java SE 9, so it is not the fault of Java EE or Jakarta EE in that case.

To me, it does not matter whose fault it is. What matters to me is that it breaks my expectations. I think that not providing technologies that were available in Java EE 8 (even if they came from Java SE) is very risky for the future of the project because it runs contrary to the expectations of backwards compatibility that might exist. In my opinion, backwards compatibility is essential and in the special case of Jakarta EE it is not only about what's actually in the specs but also about the perception of changes by the community.

> Offering this in a way that allows applications to use it but not necessarily blow up the Full Jakarta EE stack more (instead of also removing stuff) Sounds reasonable.

A more comprehensive Full Jakarta EE profile is an asset from my point of view. The more technologies it contains, the more functionality I can implement in pure Jakarta EE without having to rely on external libraries.

I'd prefer more profiles with a reduced set (e.g. "Cloud" or "Opinionated REST") over a smaller full profile. A newer, bigger profile (e.g. "Everything but the kitchen sink") would also be fine with me. However, AFAIK Jakarta EE 9 won't contain any new profiles so what's important for me is what is in the full profile.


Kind regards,

Erik Brangs
_______________________________________________
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@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