Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] API compile source and target levels
For those of you unable to attend the Platform call this week (https://docs.google.com/document/d/1EJ2ilaPhMnQqa3aw6AmwjRbBPGL3_np4uuwklgfqPZI/edit?nbsp#), here is the conclusion for this API source/target level...

  • Minutes:
    • The recommended combining of the two bullets (Major and Minor version) is approved.  We will leave this as a “recommendation” and not a “requirement” to allow component APIs to stay at a lower JDK level if the move to Java 11 is not a requirement.
      • If your component Specification is planning a Major or Minor 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.
    • Any building of the API jar files should use the “--release” option to the compiler (instead of the source/target java levels).
      • <maven.compiler.release>11</maven.compiler.release>
  • The Platform and Web Profile uber API jar files will all be re-built with the Java 11 target level (consistent with past practices).
    • For Jakarta EE 10, we will keep creating the uber JARs but indicate they are being deprecated
    • Later versions of Jakarta EE may remove these uber JARs
    • BOMs are already being generated and distributed
I will update the jakartaee-api Issue (https://github.com/eclipse-ee4j/jakartaee-api/issues/107) as well...  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)



From:        "Brian Stansberry" <brian.stansberry@xxxxxxxxxx>
To:        "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        07/08/2021 17:25
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] API compile source and target levels
Sent by:        "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>



All of the below makes sense to me. I'm glad to see this topic being handled this way, i.e. striving to avoid driving binaries to do new releases when they'd otherwise work fine.

On Thu, Jul 8, 2021 at 7:39 AM BJ Hargrave <hargrave@xxxxxxxxxx> wrote:
For binary compatibility, which is the purpose of semantic versioning, we need to think of existing binaries (libraries and application) and not the Jakarta EE implementations. 
 
Recompiling an existing Jakarta EE API (assuming no semantic change to the API) to change the target to Java 11 does not affect existing binaries using the API. They can continue to run unchanged on a new Jakarta EE 10 implementation which itself will require Java 11. But the existing binaries do not require any change at all.
 
If you change the major version of the Jakarta EE API just because you change the target to Java 11, then you signal to everyone that existing binaries using that API cannot work on Jakarta EE 10 implementations which becomes yet another major inflection point and shows instability in Jakarta EE evolution.
 
So if there is no change to a Jakarta EE API for Jakarta EE 10, then no need to rebuild and republish API artifacts. So the existing artifacts with target 8 are just fine.
 
If Jakarta EE API is getting a minor or major semantic change for Jakarta EE 10, then compile for target Java 11. Since a minor semantic change does not affect existing binaries, they will work fine with the new API running in a Jakarta EE 10 implementation on Java 11. Any code which wishes to use the changes (minor or major) in the Jakarta EE API will need source code changes and recompilation and will also have a runtime dependency on a Jakarta EE 10 implementation, so there is no downside for the Jakarta EE API artifact to be target Java 11.
 
So just recompiling for target Java 11 does not constitute a semantic change in the API in that existing binaries work without change. So it is wrong, and sends a bad message to the market, for us to change the major version of and API just for a change in target.
 
So Kevin, to your 3 bullets, I am happy with them. With respect to bullet 2, I would also be happy with just saying use target Java 11 since no new binary can use the new semantics of the API without running on a Jakarta EE 10 implementation which itself will require Java 11.
--

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 developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] API compile source and target levels
Date: Wed, Jul 7, 2021 18:56
 
Thanks, BJ.

I'd like to try to get the discussion going again here on the mailing list instead of waiting for the call and hoping that everyone shows up...  Maybe we can finalize this on the next call.

To clarify...  You are indicating that just because an API is getting compiled at a new Java target level, that does not affect the binary compatibility of the API.  Yes, the java runtime dependency has changed, but the API itself is still binary compatible.  The decision of whether to update the Major or Minor version should be solely on the changes to the API itself, not based on the Java target level.

If I have this right, then the following updates are required to my earlier statements:
  • 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, you are welcome to do that.
  • 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.  If you feel compelled to recompile and distribute at the Java 11 target level, then plan for a service release (x.y.z) to indicate the change.
  •  
Better?  Thanks again!

---------------------------------------------------
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)



From:        "BJ Hargrave" <hargrave@xxxxxxxxxx>
To:        jakartaee-platform-dev@xxxxxxxxxxx
Date:        07/07/2021 17:17
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] API compile source and target levels
Sent by:        "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>



> 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)
 
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev



 
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
 



_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev




--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev




Back to the top