Replies: 3 comments 9 replies
-
|
Probably we'll just want to wait to some features after Java 17 until we get both the current and the stable branch to be TCK certified, as doing this way we can backport the fixes easily. After that, I think we can start using the new features in the current branch. But if a change is not a bug fix or a TCK fix, I think we can use the new features, as this change won't be backported. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly ;) |
Beta Was this translation helpful? Give feedback.
-
|
Similarly if you opt for the upcoming 'stable' branch we only support it on Java 17. That way we only have to worry about 2 Java versions for now! |
Beta Was this translation helpful? Give feedback.
-
|
@mnriem Will the stable branch receive updates like the support for Servlet 6+, or will it stay on 5.0? |
Beta Was this translation helpful? Give feedback.
-
|
If we would do that we would have to keep current syntax wise on the current LTS but run use the latest Java, which I would be fine with. That would allow us to always adopt the latest Servlet / Jakarta EE release when it comes out with the current LTS Java version and make it the new production branch. And the older Servlet / Jakarta EE based version would then become the stable branch. So expressed using which branches (would) exist:
If Servlet 6 comes out before new Java LTS
Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
And then once the new LTS comes out the current and production with uptake the new LTS for source and runtime. But only the current branch will keep tracking latest Java for runtime. |
Beta Was this translation helpful? Give feedback.
-
|
It will also be interesting to see when Java SE exactly removes the Security Manager and classes such as If those classes are actually removed, we can't use those API artefacts on that JDK version until those artefacts are cleaned. Same holds for implementation components that we use. I'm trying to make people aware these classes are going to disappear and that instead of fixing things by adding privileged methods and such, it's better to bite the bullet and remove them already. |
Beta Was this translation helpful? Give feedback.
-
|
That is indeed another concern that we need to be keenly aware of. Note I have some ideas when/if that happens before EE releases catch up with changes in the JDK but this won't change the outline mentioned above. |
Beta Was this translation helpful? Give feedback.
-
|
See also jakartaee/platform#406 |
Beta Was this translation helpful? Give feedback.
-
|
Can we use new features from other components, like Javadoc in the current branch? It won't change the source code version, but we can have some new features, like this one: https://twitter.com/gunnarmorling/status/1449820238061703226 |
Beta Was this translation helpful? Give feedback.
-
|
Once Java 18 becomes available from Adoptium.net I would have no problem with that provided the sources indeed stay on Java 17 ;) |
Beta Was this translation helpful? Give feedback.
-
After Java 17 drops we are thinking about adopting the following:
Renaming master branch to current
The 'current' branch will continue on updating to newer Java versions and is allowed to make backwards incompatible changes. Note any releases cut from this branch will use Y.M.p.
A 'stable' branch will be created which is kept on Java 17 and needs to be kept backwards compatible. Note any releases cut from this branch will use 21.10.x where x will be incremented for any release. Note any bugs that need to be/are fixed because of TCK violations are exempt from the backwards compatibility rule as our runtime MUST be (kept) TCK compatible.
Thoughts?
@arjantijms @Thihup
Beta Was this translation helpful? Give feedback.
All reactions