Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide common Java version detection #921

Merged
merged 6 commits into from
Sep 13, 2021
Merged

Provide common Java version detection #921

merged 6 commits into from
Sep 13, 2021

Conversation

fvgh
Copy link
Member

@fvgh fvgh commented Aug 25, 2021

The approach of GoogleJavaFormatter to provide default versions depending of the JRE Java version has been extracted to a generic class. The code duplicated in testlib JRE has been removed.

Furthermore the approach has been extended:

  • It allows to check whether a formatter version is supported by the current JRE. This approach allows to provide proposals about other formatter versions to the user.
  • It provides version proposals not requiring a JRE upgrade if possible.

For these extensions the amount of code has been increased. It needs to be discussed whether the benefit is worth the increase of code complexity.

@fvgh fvgh force-pushed the common_jvm_detection branch from 80ba06d to ae70362 Compare August 25, 2021 19:20
@fvgh fvgh requested a review from a team August 25, 2021 19:32
@fvgh
Copy link
Member Author

fvgh commented Aug 25, 2021

There is still work in progress. Tests are missing. Comments on scope and readability of the new Jvm class are more than welcome.

@fvgh fvgh marked this pull request as draft August 25, 2021 19:35
Copy link
Member

@nedtwigg nedtwigg left a comment

Choose a reason for hiding this comment

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

I think this is an awesome idea. I have one general concern which I outlined below. I suppose we could watch for new releases of all the formatters which we support and be more proactive about bumping our defaults. I don't think we maintainers should have to do all of that, but we could generate error messages which encourage people to generate PRs, it's very easy for us to merge and cut releases for them.

But I tend to think that it's too noisy for us to release a new Spotless any time any one of our formatters releases a new version. If the average project releases N times per year, and we support M formatters, then we are going to have to release N*M times per year, and that creates noise for anyone who is trying to keep their Spotless up to date.

@fvgh
Copy link
Member Author

fvgh commented Aug 28, 2021

release a new Spotless any time any one of our formatters releases a new version

I think it is beneficial for the users when default versions are increased frequently, since the user only needs to increase the Spotless version. But I think that everybody who automated the formatting with Spotless can wait for a few month for a new release. So just because someone updated a formatter version, I don't see the need that a new Spotless release follows a few days later.

This JVM check is just another assistance utility, since many projects still stuck with Java 8.

@nedtwigg
Not sure about your general remarks. Do you mean that instead of having a few utility functions, we should aim for something different?

@nedtwigg
Copy link
Member

nedtwigg commented Aug 30, 2021

After your most recent changes this whole thing looks great to me.

Ironed out corner cases.
Added Support#verifyConfiguration.
Slight modifications in wording and method names (see
GoogleJavaFormatStep / GoogleJavaFormatStepTest).
Comment on lines 94 to 111
public void verifyConfiguration() {
if (jvm2fmtVersion.size() > fmt2jvmVersion.size()) {
throw new AssertionError("The added support information contains duplicated formatter versions.");
}
if (jvm2fmtVersion.size() < fmt2jvmVersion.size()) {
throw new AssertionError("The added support information contains duplicated JVM versions.");
}
jvm2fmtVersion.forEach((jvmVersion, fmtVersion) -> {
Map.Entry<Integer, V> lower = jvm2fmtVersion.lowerEntry(jvmVersion);
if ((null != lower) && (fmtVersionComparator.compare(fmtVersion, lower.getValue()) <= 0)) {
throw new AssertionError(String.format("%d/%s should be lower than %d/%s", jvmVersion, fmtVersion, lower.getKey(), lower.getValue()));
}
Map.Entry<Integer, V> higher = jvm2fmtVersion.higherEntry(jvmVersion);
if ((null != higher) && (fmtVersionComparator.compare(fmtVersion, higher.getValue()) >= 0)) {
throw new AssertionError(String.format("%d/%s should be higher than %d/%s", jvmVersion, fmtVersion, higher.getKey(), higher.getValue()));
}
});
}
Copy link
Member Author

@fvgh fvgh Sep 12, 2021

Choose a reason for hiding this comment

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

@nedtwigg
I moved unnecessary checks to an external method. My problem with Jvm.Support is the static configuration. It fits best with the current formatter step implementations, but it is not lazy. So I prefer to do sanity checks in the UTs.
What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

Darn, my comment showed up twice, so I deleted one and they both got deleted :(

I think the sanity checks are fast enough that they cost ~0 to users, but adding a chore to the unit tests costs 10s of minutes per PR, so I lean very lightly towards making the verification automatic rather than adding them to a unit test checklist. I'm fine either way though, the core idea here is good.

# Conflicts:
#	lib/src/main/java/com/diffplug/spotless/java/GoogleJavaFormatStep.java
#	testlib/src/test/java/com/diffplug/spotless/java/GoogleJavaFormatStepTest.java
@fvgh fvgh force-pushed the common_jvm_detection branch from 6824987 to 30336b1 Compare September 12, 2021 13:25
@fvgh fvgh marked this pull request as ready for review September 12, 2021 13:47
@fvgh
Copy link
Member Author

fvgh commented Sep 12, 2021

@nedtwigg Propose to do a "squash and merge". Didn't want to do a rebase and merged main instead to keep track of the conflicts.

Copy link
Member

@nedtwigg nedtwigg left a comment

Choose a reason for hiding this comment

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

This is looking great to me :)

@fvgh fvgh merged commit 7b90966 into main Sep 13, 2021
@fvgh fvgh deleted the common_jvm_detection branch September 13, 2021 18:51
@nedtwigg
Copy link
Member

Btw, squash and merge sounds good, I'll let you push the button when you're ready. If there's more you want to put in this one then take your time :)

@fvgh
Copy link
Member Author

fvgh commented Sep 14, 2021

@nedtwigg Tripped again over the circle-ci test_nomaven... problem, but saw that com.diffplug.spotless:spotless-eclipse-groovy:4.2.0 was published.

However, I am afraid we made a mistake when closing #877.

I never published a com.diffplug.spotless:spotless-eclipse-groovy:4.1.1, nor did I do an update afterwards of the corresponding dependency locks in lib-extra. Hence we never provided a fixed version. Think we owe @k-brooks a big apology.

I will provide all formatter updates for Eclipse 4.20 at this weekend. But they will all require JVM 11+.

@k-brooks : Sorry, about the inconvenience. Is Eclipse 4.20 / JVM 11+ fine for you, or do you need JVM 8 support?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants