MicroProfile release based on Jakarta EE 8 APIs

[Ken Finnigan]

This is a "renaming" of John's thread [1], as I realized the title might have been confusing.

We discussed in this week's hangout the possibility of moving from a base of Java EE 8 APIs to Jakarta EE 8 APIs, but wanted to follow up here to get additional feedback.

The first question is when we want to update to Jakarta EE 8 APIs? Some of those on the call expressed a desire to move as soon as possible, while others felt it better to wait for Jakarta EE 9.

If the answer to the above is yes, please provide feedback on whether updating to Jakarta EE 8 APIs would be a 3.x or 4.0 release? One concern with it being a 4.0 is the potential for a 5.0 in the same year, depending on when Jakarta EE 9 were to be released.

As the APIs themselves are identical, there is an argument to be had that updating to Jakarta EE 8 would just be a 3.x release.

Please provide feedback to the above so that we can begin to plan accordingly.

Ken

[1] - https://groups.google.com/forum/#!topic/microprofile/bkHtO_JhB9M

[Werner Keil]

I think the idea of updating sooner is good and internally the Java API has not changed yet, so there should be almost no change to the code because of that. Without otherwise drawing a comparison, but downstream dependency analysis on GitHub or Mavencentral show, especially Spring Boot is already using the new Jakarta EE specs that are part of Jakarta EE 8 like Jakarta Validation, Jakarta Messaging, etc. The version was only increased from 2.1.x to 2.2.x, thus a 3.x upgrade behind the major decimal pointer seems just to the actual changes.

Although the Jakarta EE contributions and meeting the timeline gives us reason to hope for a not too long availability of Jakarta EE 9, the namespace changes beyond the Java package is more risky and will require more testing if we want to avoid the bad press and reception of iOS 13 which seemingly got rushed into Apple's iOS event last month without really being ready in many places ;-/

So it could take a bit and MicroProfile might risk seeming outdated if it waits for Jakarta EE 9.

Werner

[Ondro Mihályi]

I agree with Werner. Waiting for Jakarta EE 9 could be too long. Switching to Jakarta EE 8 would send a positive message and show encouragement for Jakarta EE. No need to update to MP 4.0 just because of that as there are no API changes. The change should only be in the spec document and maven dependencies.

Ondro

[Alex Lewis]

Somewhat double posting this here from the other thread...

I think there was some concern over MP having Jakarta EE 8 dependencies whilst the App itself may depend on Java EE, thus duplicating the classes and any problems that may or may not cause.

As I think the package names for classes Jakarta EE 8 are still in the javax.* namespace I think an app developer could disable the MP's dependency on Jakarta GAVs and add the Java EE GAVs to their own POMs (if they're not there already). As the classes are binary compatible, the Application and MP would all be using Java EE 8 binaries instead.

This may mean that MP might be considered backwards-compatible as it would use the Jakarta EE binaries/dependencies by default but there is a route those apps that specifically need Java EE 8. As such, it could make the change in a minor release. As long as you think having to change the App POM is not a break in backwards-compatibility.

The below is an example but I admit I've not actually tried it.

E.g.

<dependency>
  <groupId>org.eclipse.microprofile</groupId>
  <artifactId>microprofile</artifactId>
  <version>X.Y</version>
  <exclusions>
    <exclusion>
      <artifactId>jakarta.enterprise</artifactId>
      <groupId>javax.enterprise.cdi-api</groupId>
    </exclusion>
   <exclusion>
      ... etc....
  </exclusions>
<dependency>
<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>8.0</version>
    <scope>provided</scope>
</dependency>

[Emily Jiang]

Adopting Jakarta EE8 in Feb release makes sense and I think this should send a positive signal to our customers about Jakarta.

Even though the switch to Jakarta EE8 looks small, it does mean that MicroProfile will need to rely on Jakarta CDI, JAX-RS, JSON-P, JSON-B maven coordinates for the MicroProfile Feb BOM. The MP runtimes need to provide that. Do we need to ensure MicroProfile Feb release can be consumed by MP runtimes that have not consumed Jakarta EE8? There are some complications on an app requiring Java EE8 jars and Jakarta EE8 jars, as discussed in the hangout.

As for whether to bump major versions or not, as mentioned in my other email in John's thread, MicroProfile Fault Tolerance plans a backward incompatible changes and would like to get into Feb release. If this is acceptable, this is a strong justification for a major release. Even if Jakarta EE9 is released next year, we might be able to do a release just consuming that with a special release. I don't see an issue there though.

Besides, when we rebase MicroProfile to Java EE8 from Java EE7, we bumped our MicroProfile version though, even though Java EE8 is backward compatible to Java EE7.

My 2cents.

Emily

[Alasdair Nottingham]

I said this in the other thread, but I think we should do this, but not bump the major version. I think it would make it look as if Jakarta EE 8 is a breaking change when it is not. I think that would undermine the efforts at Jakarta EE. 

Sa result I don’t think a major release in Feb makes sense. I think we should hold to June. To be honest if Jakarta EE 9 is to come by September next year I think I’d suggest holding off on breaking changes until we uplift to Jakarta EE 9. 

Alasdair Nottingham

On Oct 2, 2019, at 1:30 PM, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/185180c0-61ea-4cc2-af86-73c5a79d5231%40googlegroups.com.

[Andy Guibert]

+1 for adopting Jakarta EE 8 and including it in a MP 3.x release.

If we went to 4.0, that would imply a breaking change somewhere in the platform which is certainly not the case going from Java EE 8 to Jakarta EE 8.

- Andy

[Gordon Hutchison]

Hi Folks,

I think we should do everything we can to help Jakarta where this not painful.

To make an engineering based decision I would need to know the exact list of

"MicroProfile Fault Tolerance [plans a] backward incompatible changes", the new

features delivered in the release, an idea of who is waiting for them and the 'next best' ship

date for MP FT.

I guess vendors could 'pre-ship' a spec impl if the content was frozen?

If so it would be MP bom's etc?

Given that we believe the jars are binary identical - what about the idea of showing that

Jakarta EE 8 is so binary compatible that we have 1 set of built jars and two sets of pom's/bom's? (based on Java EE and Jakarta EE)?

Users can pick either. It might make a news story if nothing else

Right now I would vote for demonstrating how compatible Jakarta is with a small version increment,

agreeing with what Andrew, Alasdair and Kevin (spoken on the hangout last week) have said.

We need to do everything we can to work well across Jakarta-Microprofile as one 'community'

and that involves helping neighbours even if it might be a slight local de-optimisation.

Gordon

[Ken Finnigan]

For now, I would suggest not worrying about a possible breaking change release from Fault Tolerance and just focus on whether we should update to Jakarta EE 8 APIs and what version number that would be for MP platform, presuming no other breaking changes.

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a6435196-c0a7-4fd4-ae6f-555ae1f17d4d%40googlegroups.com.

[Gordon Hutchison]

Under the constraints you specify Ken (ignore FT and the idea of having multiple boms/poms for the same jars for now)

I would be, to quote Andy,...

+1 for adopting Jakarta EE 8 and including it in a MP 3.x release.

Gordon.

On Monday, 7 October 2019 13:26:16 UTC+1, Ken Finnigan wrote:

For now, I would suggest not worrying about a possible breaking change release from Fault Tolerance and just focus on whether we should update to Jakarta EE 8 APIs and what version number that would be for MP platform, presuming no other breaking changes.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[John Clingan]

The problem is that we have no idea when the Jakarta EE namespace change will happen. It could be Q1 or Q2 calendar 2020, but it is also possible that it could be Q3 2020. The latter case would mean:

• Feb 2019: MicroProfile 3.2. Jakarta EE spec alignment
• Jun 2020: MicroProfile 4.0. The June release is designated for major releases. This would include Fault Tolerance release
• Oct 2020: MicroProfile 5.0. Jakarta namespace change

There is a very good chance  that there will be two Major releases within a year. We have a couple of months to see what progress is made on the Jakarta EE namespace change.

As a side comment, the Fault Tolerance team can continue to release the major version standalone and it can be included in the next major platform release. A runtime can choose to offer more than one spec version implementation and let the user choose.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Alasdair Nottingham]

If we know that Jakarta EE 9 will be out in September then perhaps we should discuss whether we should have MP 4.0 in October rather than in June to avoid this. I suspect the Fault Tolerance team would not be in favour of that, but I think it should be an option that is discussed.

Alasdair

> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a6435196-c0a7-4fd4-ae6f-555ae1f17d4d%40googlegroups.com.
>

> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/10fc0bdb-b531-4b28-919c-e2825fefb60b%40googlegroups.com.

[John Clingan]

FYI, we do not know that. I was just giving an example date.

> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a6435196-c0a7-4fd4-ae6f-555ae1f17d4d%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Alasdair Nottingham]

Agree, but I think there is a good chance it’ll be a year after Jakarta EE 8 at which point it would be after June hence me suggesting we should be flexible around the next major release. I don’t think we need to make any decision until much closer to the June release when I would hope we would have better idea of Jakarta EE’s plans.

> > To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a6435196-c0a7-4fd4-ae6f-555ae1f17d4d%40googlegroups.com.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/10fc0bdb-b531-4b28-919c-e2825fefb60b%40googlegroups.com.
>
>

> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/eabdac81-5bc4-4688-8284-c812c0b894fe%40googlegroups.com.

[Ondro Mihályi]

Hi all,

According to the discussion in this Jakarta EE thread: https://www.eclipse.org/lists/jakartaee-platform-dev/msg00702.html, the majority expressed the desire to deliver Jakarta EE 9 ASAP, even without any additional changes to the API, just transition to the jakarta prefix. That may mean that Jakarta EE 9 would be easily delivered during next the year, maybe even in time for the MP June release.

I would wait how Jakarta EE 9 progresses and if it's released or close to be released around June next year, I'd rather base MP 4.0 release on Jakarta EE 9, even if it's postponed to the October release with all the other breaking changes in FT and other specs. It wouldn't block FT from releasing a new major release with breaking changes, it would just wait until MP 4.0 to be included in an umbrella release.

Ondro

> > To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a6435196-c0a7-4fd4-ae6f-555ae1f17d4d%40googlegroups.com.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/10fc0bdb-b531-4b28-919c-e2825fefb60b%40googlegroups.com.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Emily Jiang]

After Jakarta EE9 is released, I think we will have to wait for at least a couple of runtime to support Jakarta EE9 first. Right? I think June release is very unlikely for MicroProfile to base on Jakarta EE9. Maybe we should still keep June release as MicroProfile major release. When Jakarta EE9 is released with a couple of compliant runtime, how about make a special one-off release for it? In this way, the uncertainty on Jakarta EE9 release date will not impact MicroProfile specification progress.

Thoughts?

Emily

[Ken Finnigan]

Please move any talk about Jakarta EE 9 and MP to a new thread, as that is not the purpose of this discussion.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7e3ef825-d9cf-4735-8c78-bafd13bf2875%40googlegroups.com.

[Mark Little]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe7nfWxrupaxp%3Deg-j_Th8qBN4aiPsZtQyN%2BvYAb%3D9bEdw%40mail.gmail.com.

[Gordon Hutchison]

Those interested in this topic may find

https://github.com/eclipse/microprofile/pull/134

interesting.

It switches the transitive dependencies that a customer

using an API jar's pom will pull in between Jakarta and JavaEE

based on

mvn -Djakarta

for their build using a profile (multiple maven profiles, e.g. {release,jakarta} can be active at once).

Gordon

On Tuesday, 1 October 2019 19:45:45 UTC+1, Ken Finnigan wrote:

[Kevin Sutter]

Sorry, I'm late to this conversation.  I thought this move to the jakarta ee 8 apis would be a no-brainer.  Since the APIs themselves are identical, there is no reason to hesitate moving to the jakarta ee 8 maven artifacts.  We should do this asap (next release in Feb 2020).  This should not require a major version upgrade.  Since we're trying to complete the re-spin of the 3.2 release, the Feb release should be 3.3 and include this jakarta ee 8 api update.

I see no reason why we need an alternate build mechanism to differentiate (ie. "mvn -Djakarta" idea).  Whether you build against the Java EE or Jakarta EE artifacts, there should be no effect.  We've proven that with the several Jakarta EE compatible implementations and their associated customer bases.

Thanks,
Kevin

[Gordon Hutchison]

Going 100% Jakarta is even better from my point of view.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Ae2yQ5Er1Hk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d7d9f817-1483-4254-9371-1e004a26ba0a%40googlegroups.com.

[Ondro Mihályi]

+1 for switching 100% to Jakarta EE 8. No reason to keep using Java EE 8 as it's the same thing wrapped in a different package. Jakarta EE 8 is a drop-in replacement for Java EE 8 and makes no difference.

Ondro

To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.

[Arjan Tijms]

Also +1 for switching to Jakarta EE 8 asap. There's no technical reason whatsoever to delay that.

[Rhuan Henrique]

+1 to Jakarta EE 8

On Wed, Nov 20, 2019, 06:57 Arjan Tijms <arjan...@gmail.com> wrote:

Also +1 for switching to Jakarta EE 8 asap. There's no technical reason whatsoever to delay that.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/41c87e1a-b6e3-442c-9743-64f931ba690b%40googlegroups.com.