Skip to content

Upgrade from Java 11 to Java 17#47

Open
PhilippWendler wants to merge 12 commits intomainfrom
java17
Open

Upgrade from Java 11 to Java 17#47
PhilippWendler wants to merge 12 commits intomainfrom
java17

Conversation

@PhilippWendler
Copy link
Copy Markdown
Member

@PhilippWendler PhilippWendler commented Mar 10, 2026

JavaSMT is also doing this, so all projects depending on this library are now at Java 17 or newer.

The PR updates the build config and then applies several commits that make use of Java 17 features (pattern-matching instanceof, new switch syntax, String.formatted(), and sealed classes). Most of the commits are auto-generated.

For reviewing, the interesting questions are:

  • Are the updates in da795f1 correct and complete, for example with regards to all IDE configs?
  • Are the records introduced in da795f1, 624df6b, and aef9ced backwards compatible with the previous classes? AFAIU and with my tests in CPAchecker this should be the case.
  • Of course if there is anything that I have overlooked and that would be nice to improve with a Java 17 feature I am also glad to be pointed to it.

Fixes #46.

All known users of this library also require Java 17 anyway.
Commit generated automatically with Google Error Prone.
Commit generated automatically with Eclipse.
Commit generated automatically with Google Error Prone.
Commit generated automatically with Google Error Prone.
There were only two cases where
google/error-prone#4866 could be a problem,
these were checked and handled manually.
Any other instances of that bug would be detected by Error Prone,
which checks the number of format arguments.
The disadvantage is that now the constructor is public,
but for this class it does not hurt.
The change should be binary and source compatible because we keep all
public methods, and nobody could inherit from the old class.
The disadvantage is that now the constructor is public,
but for this class it does not hurt.
The change should be binary and source compatible because we keep all
public methods, and nobody could inherit from the old class.
These are only cases that are not public
or where inheritance was already prevented with a private constructor.
@PhilippWendler
Copy link
Copy Markdown
Member Author

@kfriedberger Are you interested in looking at this?

Copy link
Copy Markdown
Member

@kfriedberger kfriedberger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a quick review. Changes look good to me.

String.format(
"The option %s specifies the path '%s' that is forbidden in safe mode " + reason + ".",
FluentIterable.<Object>of(optionName, path).append(args).toArray(Object.class)));
("The option %s specifies the path '%s' that is forbidden in safe mode " + reason + ".")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you mix formatter and concatenation here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I also stumbled over this. The reason is that reason is a (part of the) format string. I added a comment explaining this.

Thanks for having a look!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Bump minimum Java version to 17

2 participants