-
Notifications
You must be signed in to change notification settings - Fork 459
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
Conversation
80ba06d
to
ae70362
Compare
There is still work in progress. Tests are missing. Comments on scope and readability of the new |
There was a problem hiding this 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.
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 |
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).
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())); | ||
} | ||
}); | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
6824987
to
30336b1
Compare
@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. |
There was a problem hiding this 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 :)
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 :) |
@nedtwigg Tripped again over the circle-ci However, I am afraid we made a mistake when closing #877. I never published a 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? |
The approach of
GoogleJavaFormatter
to provide default versions depending of the JRE Java version has been extracted to a generic class. The code duplicated intestlib
JRE has been removed.Furthermore the approach has been extended:
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.