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

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.

 

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.

 

Werner

 

Sent from Mail for Windows 10

 

From: Erik Brangs
Sent: Wednesday, November 27, 2019 19:10
To: jakartaee-platform-dev@xxxxxxxxxxx
Subject: Re: [jakartaee-platform-dev] VOTE: Specifications to add inJakartaEE 9

 

Hi,

 

On 27.11.2019 07:05, Markus KARG wrote:

> As Java EE 8 had Java SE 8 as a mandatory dependency, and as Java SE 8 had JAXB as a mandatory part, it is clear that many people see it as "removing" if we do not "add" it: They wrote a Java EE 8 compliant application and it won't work any more on Jakarta EE 9.

 

That's certainly my view.  If you don't add them for Jakarta EE 9, this might be a nasty surprise for a lot of people. I'm not sure if there are any statistics about this, but not everyone follows the development of Jakarta EE closely enough. I suppose most people only read what's in the release when it's done. Some may not even read about it until they actually want to migrate.

 

I'd prefer for these technologies to be added to Jakarta EE even if they don't evolve. I know it's more work but I think it's crucial to do this to keep up the tradition of backwards compatibility that Java EE has. You can make them optional later, possibly even in Jakarta EE 10.

 

With regards to specific technologies, I understand if JAX-WS isn't added to the Full Platform although I disagree with this approach. However, I don't understand not adding JAXB to the Full Platform. In my view, JAXB is a core enterprise technology and belongs into Jakarta EE.

 

XML is still used in APIs and protocols that are vendor-independent and actually have a specification (rather than merely some API documentation). In particular, XML isn't going away for existing protocols. People aren't going to switch their APIs and protocols from XML to JSON just because JSON might be a better choice now. They'll only consider switching if the protocol requires an update anyway.

 

 

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

 


Back to the top