> The reasoning behind this is that a recompile and redistribution of an API at a higher Java target level would constitute a semantic "breaking change" and, thus, require a Major version update.
This seems to go completely against the discussion and conclusion from the 6/22 call. From the 6/22 minutes:
> CONCLUSION: As long as existing binaries still work, it’s just a minor update. Binary compatibility is preserved.
If we are going to revisit already decided things, it is important to get those involved in the prior decision in the discussion again. Both Tom Watson and myself did not make the call this week and we still support the original conclusion from 6/22. So, I think this still needs more discussion.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
----- Original message -----
From: "Kevin Sutter" <sutter@xxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform-dev" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] [jakartaee-platform-dev] API compile source and target levels
Date: Wed, Jul 7, 2021 15:16
Following up on a couple of recent Platform Call discussion points...
Currently, the Platform and Web Profile API uber jar files are compiled at the Java 8 source and target levels. Based on the proposed move to Java 11 as the new minimum, these uber jars will now be compiled at the Java 11 source and target levels.
A few notes concerning this update...
- Documenting the update via this Issue: https://github.com/eclipse-ee4j/jakartaee-api/issues/107(comments welcome here or in the Issue)
- There is no requirement for individual component Specification APIs to compile at the Java 11 source/target level. The change I am referring to is for the Platform and Web Profile API uber jar files only.
- If your component Specification is planning a Major version update for Jakarta EE 10, then the recommendation would be to recompile and distribute your APIs at the Java SE 11 source/target levels.
- If your component Specification is planning a Minor version update for Jakarta EE 10, then the recommendation is to continue compiling and distributing your APIs at the Java 8 source/target levels. If there is a compelling reason to recompile your APIs at Java 11 target level, then you may need to re-do your Release Plan as a Major version update.
- If your component Specification is not planning either a Major or Minor version update for Jakarta EE 10, then just leave your APIs as-is.
- The reasoning behind this is that a recompile and redistribution of an API at a higher Java target level would constitute a semantic "breaking change" and, thus, require a Major version update. To avoid requiring all Specifications to do a Major version update for Jakarta EE 10, allowing existing APIs to remain at Java 8 (or even earlier in one case) is a fine alternative.
- One last note... There was some discussion about just discontinuing the creation of these uber jars. At this point, there is still enough interest and usage of these uber jars to warrant continued generation and distribution. If and when JPMS creeps into the Platform and Profile API jar files, then this decision may need to be revisited. But, for Jakarta EE 10, we're going to continue creating them.
Comments welcome here or via the Issue. Thanks!
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
