Minimum Java Level for MP 4.0?

[Andy McCright]

Hi All,

Sorry if I missed it in another thread, but has there been any consideration to raising the minimum Java level for MP 4.0?  

I am particularly interested in using Java 11 in order to use the Flow APIs introduced in Java 9 in MP Rest Client 2.0.  They replace the Reactive Streams API that some of the Reactive projects use. This would obviously be a breaking change for Reactive Streams Operators as well as Rest Client (which is already expecting to include breaking changes), and so it might be better to do that in the upcoming 4.0 release, rather than waiting until the 5.0 release in Summer 2021.  

Thanks,

Andy

[Werner Keil]

If the Flow API was introduced in Java 9, then I'm not sure, how well a minimum version of Java 11 would be received?

Why not use the Multi-Release JAR feature?

Werner

[Emily Jiang]

Hi Andy,

There is no intention to rasie Java version in MP 4.0. I think it is best to raise the minimum Java version when we consume Jakarta EE9 (IIRC, I think we discussed this in the past).

They replace the Reactive Streams API that some of the Reactive projects use. This would obviously be a breaking change for Reactive Streams Operators as well as Rest Client (which is already expecting to include breaking changes), and so it might be better to do that in the upcoming 4.0 release, rather than waiting until the 5.0 release in Summer 2021. 

Reactive Streams Operators doesn't require Java11. It depends on org.reactivestreams instead of Java 9 Flows. Once MP raises its minimum Java version to Java 11, Reactive Streams Operators can be changed to depend on Java 9 Flow. In Rest Client, if you need to depend on Flow API, you might consider to depend on org.reactivestreams and then update to depend on Java 9 Flow when the minimum Java version in MP is raised to Java 11.

Emily

[Andy McCright]

Hi Emily, Werner,

Thanks for the replies.  

The issue is the dual maintenance involved with supporting implementations of both Reactive Streams and Java Flow APIs - yes, I think MR JARs could allow both options to work, but still requires the extra maintenance that I would like to avoid.

If it is not too late to change course on the decision to remain on Java 8, I'd like to suggest we re-examine our position.  Clearly, there are a lot more Java 8 users now than there are Java 9, 10, 11, 12, 13, and 14 users.  But I expect that will change.  And it will certainly help if popular frameworks (like MP and Jakarta) raise the minimum Java level.  Raising the Java level doesn't just help us (as the spec project), but also helps the implementors so that they can use modern APIs (like Flow and the Java 11 HTTP Client APIs, etc.).  Raising the Java level is clearly a breaking change, so if we don't take the opportunity in June's 4.0 release to upgrade the minimum to Java 11, then we'll need to wait until June 2021 to do it - or else authorize an off-schedule breaking release... The Java community has already released Java 14 (LTS), and even the Jakarta community is "soft" pre-req'ing Java 11.  Java 8 was great, but I think it's time to move on.  :-)

[Ken Finnigan]

Andy,

There are several issues around JDK 11 and MP that were created out of https://github.com/eclipse/microprofile/issues/106

--
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/9dc5ad06-4912-4d61-b5a3-abf45661c7cd%40googlegroups.com.

[Emily Jiang]

Hi Andy,

If it is not too late to change course on the decision to remain on Java 8, I'd like to suggest we re-examine our position.  Clearly, there are a lot more Java 8 users now than there are Java 9, 10, 11, 12, 13, and 14 users.  But I expect that will change.  And it will certainly help if popular frameworks (like MP and Jakarta) raise the minimum Java level. 

Jakarta EE9 has not raised the minimum Java level. It only asks to run at Java 11 and optional Java 8. I think a large planning needs to be set aside if we need to raise the minimum Java level in MP. I don't think MP 4.0 has enough runway for this exercise. Besides right now Java8 has the biggest customer base according to this survey.

Raising the Java level doesn't just help us (as the spec project), but also helps the implementors so that they can use modern APIs (like Flow and the Java 11 HTTP Client APIs, etc.).  Raising the Java level is clearly a breaking change, so if we don't take the opportunity in June's 4.0 release to upgrade the minimum to Java 11, then we'll need to wait until June 2021 to do it - or else authorize an off-schedule breaking release...

I think it will be ideal to sync raising the minimum Java version with consuming Jakarta EE9. We could do this either in October 2020 or Jan 2021. Normally we do major releases in June but it is not set in stone.

The Java community has already released Java 14 (LTS), and even the Jakarta community is "soft" pre-req'ing Java 11.  Java 8 was great, but I think it's time to move on.  :-)

By the way, Java 14 is not LTS (see here for details). The next LTS is Java 17. Jakarta EE9 does require the support of Java 11, but it is not released as yet. Some MicroProfile implementations do support Java 11, which was demonstrated by start.microprofile.io. Hopefully it is enough to encourage customers to move towards Java 11 and then we cut off the support for Java8.

Emily

[Guillermo González de Agüero]

Hi,

On Tue, Apr 21, 2020 at 12:02 AM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Hi Andy,

If it is not too late to change course on the decision to remain on Java 8, I'd like to suggest we re-examine our position.  Clearly, there are a lot more Java 8 users now than there are Java 9, 10, 11, 12, 13, and 14 users.  But I expect that will change.  And it will certainly help if popular frameworks (like MP and Jakarta) raise the minimum Java level. 

Jakarta EE9 has not raised the minimum Java level. It only asks to run at Java 11 and optional Java 8. I think a large planning needs to be set aside if we need to raise the minimum Java level in MP. I don't think MP 4.0 has enough runway for this exercise. Besides right now Java8 has the biggest customer base according to this survey.

MP can do the same as a first step. APIs stay at Java 8 but vendors can already move to 11 if they want, based on customer needs.

Raising the Java level doesn't just help us (as the spec project), but also helps the implementors so that they can use modern APIs (like Flow and the Java 11 HTTP Client APIs, etc.).  Raising the Java level is clearly a breaking change, so if we don't take the opportunity in June's 4.0 release to upgrade the minimum to Java 11, then we'll need to wait until June 2021 to do it - or else authorize an off-schedule breaking release...

I think it will be ideal to sync raising the minimum Java version with consuming Jakarta EE9. We could do this either in October 2020 or Jan 2021. Normally we do major releases in June but it is not set in stone.

The Java community has already released Java 14 (LTS), and even the Jakarta community is "soft" pre-req'ing Java 11.  Java 8 was great, but I think it's time to move on.  :-)

By the way, Java 14 is not LTS (see here for details). The next LTS is Java 17. Jakarta EE9 does require the support of Java 11, but it is not released as yet. Some MicroProfile implementations do support Java 11, which was demonstrated by start.microprofile.io. Hopefully it is enough to encourage customers to move towards Java 11 and then we cut off the support for Java8.

Regarding LTS versions of Java, keep in mind that's also a vendor specific concept. That link talks about Oracle Java, but Azul has taken leadership of jdk13u development and is committed to maintain it until Java 17 is out:

https://www.azul.com/products/azul-support-roadmap/

https://github.com/AdoptOpenJDK/TSC/issues/147

Emily

On Monday, April 20, 2020 at 5:20:53 PM UTC+1, Andy McCright wrote:

Hi Emily, Werner,

Thanks for the replies.  

The issue is the dual maintenance involved with supporting implementations of both Reactive Streams and Java Flow APIs - yes, I think MR JARs could allow both options to work, but still requires the extra maintenance that I would like to avoid.

If it is not too late to change course on the decision to remain on Java 8, I'd like to suggest we re-examine our position.  Clearly, there are a lot more Java 8 users now than there are Java 9, 10, 11, 12, 13, and 14 users.  But I expect that will change.  And it will certainly help if popular frameworks (like MP and Jakarta) raise the minimum Java level.  Raising the Java level doesn't just help us (as the spec project), but also helps the implementors so that they can use modern APIs (like Flow and the Java 11 HTTP Client APIs, etc.).  Raising the Java level is clearly a breaking change, so if we don't take the opportunity in June's 4.0 release to upgrade the minimum to Java 11, then we'll need to wait until June 2021 to do it - or else authorize an off-schedule breaking release... The Java community has already released Java 14 (LTS), and even the Jakarta community is "soft" pre-req'ing Java 11.  Java 8 was great, but I think it's time to move on.  :-)

On Sunday, April 19, 2020 at 4:46:55 PM UTC-5, Emily Jiang wrote:

Hi Andy,

There is no intention to rasie Java version in MP 4.0. I think it is best to raise the minimum Java version when we consume Jakarta EE9 (IIRC, I think we discussed this in the past).

They replace the Reactive Streams API that some of the Reactive projects use. This would obviously be a breaking change for Reactive Streams Operators as well as Rest Client (which is already expecting to include breaking changes), and so it might be better to do that in the upcoming 4.0 release, rather than waiting until the 5.0 release in Summer 2021. 

Reactive Streams Operators doesn't require Java11. It depends on org.reactivestreams instead of Java 9 Flows. Once MP raises its minimum Java version to Java 11, Reactive Streams Operators can be changed to depend on Java 9 Flow. In Rest Client, if you need to depend on Flow API, you might consider to depend on org.reactivestreams and then update to depend on Java 9 Flow when the minimum Java version in MP is raised to Java 11.

Emily

On Saturday, April 18, 2020 at 8:49:36 PM UTC+1, Andy McCright wrote:

Hi All,

Sorry if I missed it in another thread, but has there been any consideration to raising the minimum Java level for MP 4.0?  

I am particularly interested in using Java 11 in order to use the Flow APIs introduced in Java 9 in MP Rest Client 2.0.  They replace the Reactive Streams API that some of the Reactive projects use. This would obviously be a breaking change for Reactive Streams Operators as well as Rest Client (which is already expecting to include breaking changes), and so it might be better to do that in the upcoming 4.0 release, rather than waiting until the 5.0 release in Summer 2021.  

Thanks,

Andy

--

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/85db8129-2a8d-400c-aba9-e0c7be3500b6%40googlegroups.com.

[Emily Jiang]

Hi Guillermo,

MP can do the same as a first step. APIs stay at Java 8 but vendors can already move to 11 if they want, based on customer needs.

In fact, we have done this and the Runtime support on Java 11 are documented here.

Emily

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/mW_yixwdOJQ/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/CAG1ZpUZPgj68ktpGq9Ad4hW30L5GTpOC%2B_CngVE1FNftbp3AEA%40mail.gmail.com.

--

Thanks
Emily

[Guillermo González de Agüero]

Hi Emily,

Thanks for the link, but that seems to only document runtimes that are JDK 11 compatible. I mean MicroProfile would require JDK 11 compatibility, while keeping specs at JDK 8 to optionally support it.

Is that already the plan?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A_1n%2Bhw3ctbLCb%2BV5%2Bd4SzyKhcf6MXN%3Dn0bsQN4ukVScg%40mail.gmail.com.

[Emily Jiang]

Thanks for the link, but that seems to only document runtimes that are JDK 11 compatible. I mean MicroProfile would require JDK 11 compatibility, while keeping specs at JDK 8 to optionally support it.

Is that already the plan?

As mentioned in my previous note, the ideal time to require JDK11 is when we align with Jakarta EE9. We did discuss this in the past and I think we would revisit when we get MP 4.0 out of the way.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAG1ZpUbARKpyWuPSTVHbDsZLgp3xmDyBbspte_XatyuSpB6Cjw%40mail.gmail.com.

--

Thanks
Emily

[Werner Keil]

Hi,

Well Specs as in Jakarta EE are plain texts, usually Asciidoc, so to be precise, the API shall be binary backward compatible to Java 8, is that correct?

I would assume, that the TCK also is somewhat flexible, to not restrict vendors, isn't it?

So what artifact are we even talking about, there is no Reference implementation, therefore most implementations live outside MicroProfile anyway, so is it a recommendation for implementing vendors?

Werner

Hi,

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/85db8129-2a8d-400c-aba9-e0c7be3500b6%40googlegroups.com.

--
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/mW_yixwdOJQ/unsubscribe.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAG1ZpUZPgj68ktpGq9Ad4hW30L5GTpOC%2B_CngVE1FNftbp3AEA%40mail.gmail.com.

--

Thanks
Emily

--
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/CAECq3A_1n%2Bhw3ctbLCb%2BV5%2Bd4SzyKhcf6MXN%3Dn0bsQN4ukVScg%40mail.gmail.com.

--
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/mW_yixwdOJQ/unsubscribe.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAG1ZpUbARKpyWuPSTVHbDsZLgp3xmDyBbspte_XatyuSpB6Cjw%40mail.gmail.com.

--

Thanks
Emily

[Emily Jiang]

Hi Werner,

Comments inline.

On Tuesday, April 21, 2020 at 8:23:27 PM UTC+1, Werner Keil wrote:

Hi,

Well Specs as in Jakarta EE are plain texts, usually Asciidoc, so to be precise, the API shall be binary backward compatible to Java 8, is that correct?

As far as I know, Jakarta EE APIs are built in Java8. They can run on Java 11. Hence the compatible implementations are able to cerfiy against Java 11. However, if the API jars are built in Java 11, they won't be able to run on Java8.

I would assume, that the TCK also is somewhat flexible, to not restrict vendors, isn't it?

If APIs are built on Java 11, TCK should be on Java 11 as they need to depend on the API jars.

So what artifact are we even talking about, there is no Reference implementation, therefore most implementations live outside MicroProfile anyway, so is it a recommendation for implementing vendors?

The artifacts I meant are MicroProfile API jars.

[Werner Keil]

Hi Emily,

> However, if the API jars are built in Java 11, they won't be able to run on Java8.

Only if the release is also set to 11, otherwise you can build it with Java 15 and it will still be compatible with 8.

While 11 is an LTS, I'm not sure,if  enough apps are ready to abandon Java 8?

And especially the API JARs and elements will rarely use that many of the new 11 features, if it's for modularity, module-info can be built with the Maven Toolchain plugin or similar means to be backward compatible and expose it only to Java 9 or above.

There are many things that Java 11 breaks especially the whole XML handling, some even from 9 onward, I helped customers migrate from Java 8 to 11 and especially if XML or SOAP is involved it can be quite painful.

Why not stay at Java 8 and move to a minimum Java 11 version once Jakarta EE 9 becomes available?

Then the missing parts that were ripped out of the JDK are part of Jakarta EE and it will be less problematic.

Werner