Re: [jakartaee-platform-dev] VOTE: Specifications to add inJakartaEE 9

[Rudy De Busscher <rdebusscher@xxxxxxxxx>]

All,

For a lot of people, there is still a lot of confusion about what it actually means 'included in the Jakarta EE 9 platform'.

When an implementation wants to be recognised as 'Jakarta EE 9 compatible', it needs to implement those specifications and pass the TCK.

If we remove some of the specifications present on Jakarta EE 8 platform, that will have only an impact on the 'certification' aspect. Because I'm pretty sure that all vendors which have now a Jakarta EE 8 compatible implementation will make sure that they don't break there existing customers by just removing JAXB.

So why are we removing specifications then? To make room for new innovations, the possibility for lighter runtimes, etc .... by not requiring specifications which are hardly used.

And yes, JAXB is still used a lot. But it is a special case since it was at Java SE level and used in many other specs, also rarely used. I think Kevin indicated quite well why it could be a problem to keep JAXB.

>So, if we move JAXB to the jakarta namespace, but not JAX-WS, then we will have two different JAXB APIs to support. But, we also recognize that JAX-WS is a legacy technology that probably shouldn't be part of the long term plans for Jakarta.

Regards

Rudy

On Wed, 27 Nov 2019 at 20:32, 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