Comments inline. Basically, I agree other things might push us to JDK17
but I don't see them yet and I am just trying to see if we have consensus
to go to at least JDK11. If so, we can start the work and if we later go to 17
it will be a smaller incremental jump from 11.
On Wed, May 11, 2022 at 5:18 PM Jochen Theodorou <blackd...@gmx.org> wrote:
>
> On 11.05.22 03:05, Paul King wrote:
> > Hi folks,
> >
> > We still have a few things on our TODO list to improve Groovy 4, like
> > performance and some regressions, but we also need to start planning
> > for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
> > begin, so feel free to comment, but I don't expect many of us will
> > have time to act on big items straight away. As always, Apache
> > "do-ocracy" wins the day for starting progress on such items!
> >
> > For now, I mostly just want to tackle one aspect right now - the
> > minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
> > 4 but I think we need to bump to at least JDK11 for Groovy 5.
>
> In my experience JDK11 or higher is very widespread by now.
>
> > We have a VMPlugin mechanism which allows us to make use of features
> > in newer JDKs without bumping up the minimum version and we'd still
> > continue with that approach. However, there are many API changes in
> > the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
> > of those changes through the VMPlugin mechanism would blow out the
> > associated interface(s) substantially and limit certain choices.
> > Bumping to JDK11 provides a nice compromise on keeping just the more
> > critical functionality in the VMPlugin hierarchy and allows us to
> > start removing our usage of deprecated JDK APIs and moving to their
> > replacements in other places in the codebase. (As a concrete example,
> > groovy-console uses the deprecated modelToView method from TextUI
> > which is replaced with modelToView2D in JDK9+. It is a lot cleaner
> > just moving to the new APIs than pushing that through the VMPlugin
> > mechanism).
>
> I would not want the VMPlugin mechanism depend on graphics classes. If
> something like that, I would probably do something comparable just for
> that module as internal API.
>
> > Some other projects have moving straight to JDK17 on their roadmaps.
>
> afaik many more things have been deprecated in the time from 11 to 17
> and partially replaced with new APIs, so a JDK17 build will probably be
> required, but I would fix the decision on details. Like for example the
> upcoming SecurityManager removal.. it is deprecated in 17 already I thnk.
Re "on details": In master, we currently have @SuppressWarnings("deprecation")
on all the affected code up to JDK17. There aren't that many cases,
and basically
only 3 kinds:
* the already mentioned modelToView2D
* isAccessible() calls to become canAccess()
* getPackage() to become getDefinedPackage()
There are a few other cases but they aren't really JDK version related.
All of these would be fixed by going to JDK9 or above.
Long story short - for now JDK11 is all we need.
> > I
> > am not proposing we do that as yet but I'm interested in others'
> > views. Groovy has typically tried to keep the minimum version as low
> > as possible only jumping to when functionality dictated it as
> > necessary. Offering users features similar to what Java provides but
> > on earlier JDK versions has been one of Groovy's selling points for
> > many users.
>
> Groovy was able to run on pretty old version of Java in a time where
> Java had a quite stable API, new major versions took years and
> deprecation barely happened. That is all over now. And that means for
> Groovy that that stand is very difficult. With limited resources it is
> better to go with the new version, than to spend a lot of time in
> finding ways to conform to old and new versions at the same time. The
> last big change in the past was the support for Java5. And the changes
> required in codebase to fully switch to 5 then took many years.
>
> > Further Groovy 5 roadmap discussions may make the case
> > stronger for JDK minimum greater than 11, but for now I was proposing
> > we take the first small step and cross other bridges when we get to
> > them.
>
> I must say I do not follow the features of new Java versions all that
> much anymore. It is just too much to get used to a new version every
> half year in detail, when that is not what you are doing as part of your
> job. Java 17 being an LTS version is then of course different. But Java
> 17 does not have any features I "need" in my projects. The foreign
> memory access API could be interesting (and dangerous). But does it
> require a Groovy adaption? Sealed classes are interesting language wise.
> For me they are overengineering in class design. the whole purpose of
> those is actually supporting pattern matching with a closed set of
> classes, to be able to ensure your matching covers all cases. Afaik we
> do not even do that for enums (and I never used that even in Java)
Currently, you could use a custom type checker extension to handle
enums or sealed hierarchies but we don't currently provide that out of the box.
> > A related but orthogonal discussion we need to have is when to phase
> > out our (optional) use of the SecurityManager-related APIs (related to
> > JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
> > suggest Groovy 6 is the version for removal. Having said that, we
> > could consider parts of the codebase like groovysh as candidates for
> > removing the security manager in Groovy 5 - though the Java team
> > haven't proposed their replacement for our System.exit interception as
> > of yet.
>
> What really annoys me about
> https://bugs.openjdk.java.net/browse/JDK-8199704 and comparable ones is
> that the first deprecate an API, without having replacements for the
> obvious problems. It means that the version, that provides the new API
> will be most likely a version that has the SecurityManager removed,
> stealing from you the ability of a transition.
>
> The question is where a SecurityManager is still relevant. Applets are
> gone. That leaves server side scripting.. for example Jenkins. What do
> they think about the removal of the security manager I wonder?
Yes, it would be really good if better visibility was available on JDK-8199704
alternatives. We have about 80 occurrences of code affected by JEP-411,
all marked with @SuppressWarnings("removal"). About 1/3 is test code.
Apart from one case related to groovysh (and with a fix coming in 4.0.3)
so far up to JDK18 and some early versions of JDK19 it is safe for most
Groovy users to ignore. It degrades gracefully.
For users wanting security features (protecting access to files, allowing
only certain system properties to be read, disabling reading cut-n-paste
buffer, etc.) they need a switch on JDK18 of -Djava.security.manager=allow.
Long story short - JDK17 doesn't offer any benefit for security, i.e.
for now the jump to JDK11 minimum is all we need.
> bye Jochen
