-
Notifications
You must be signed in to change notification settings - Fork 737
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
[Feature request] Automatically disable checks based on target Java version #4208
Comments
Hi @Marcono1234! For Assuming that logic does work for you: the other checks could likely be tweaked accordingly. |
Ah sorry you are right, for
Yes that sounds like a good idea! I have extended the list above with some more checks which might be Java target version dependent. However, would it make sense to implement a more general solution which allows checks to specify an optional minimum Java version? And then maybe directly disable the checks on startup instead of executing them all the time despite them doing nothing (but still causing some overhead I guess); or can the target / source Java version differ between the files to be compiled? |
I think that could make sense, and the source version should always be the same for the entire compilation. I'm a little skeptical that the overhead of the approach |
Some checks are only relevant for a certain Java version:
JavaUtilDate
PreferJavaTimeOverload
?UnnecessaryAnonymousClass
UnnecessaryFinal
TryWithResourcesVariable
Varifier
StatementSwitchToExpressionSwitch
Would it be possible that Error Prone could automatically disable such checks based on the target Java version (
-source
&-target
/--release
) used during compilation?There would be the following advantages with this:
main
code has a lower target version than thetest
code, that would allow to enable checks which are (for now) only relevant for test code, without needing two separate compiler configurations for main and test code:OFF
for now, then it is likely that you forget to enable them againAs side note: The Error Prone checks mentioned above are currently all disabled by default and have to be enabled manually. But as mentioned in the list above, even in that case it would be useful if they would be ignored based on the Java target version (or at least there could be an opt-in Error Prone flag which makes it behave that way).
The text was updated successfully, but these errors were encountered: