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

I understand the discussion and I appreciate it happening in the mailing list for wider visibility and hopefully to avoid the discussion to go over multiple calls.
More people may feel comfortable to speak and give their view.

Anyway, bumping the runtime requirement I think is great because of the release cycle of the JVM/JDK and the old versions being unsupported.
But, I don't see the direct link with compiling in a higher source/target.

Unless we start using things from Java 8 and higher in the APIs, why would we force the source/target to be 11?
For instance, using interfaces with default methods can force us to update to source/target 11, but other than that, what's the goal or benefit of upgrading the compiler version?

Considering the impacts discussed with binary compatibility, major versioning, I'm wondering.
My mind is probably too simple or too pragmatic :-) 

My apologies if that's the case.

On Wed, Jul 7, 2021 at 9:16 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
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: 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)    

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top