-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
KAFKA-3375; Suppress deprecated warnings where reasonable and tweak compiler settings #1042
KAFKA-3375; Suppress deprecated warnings where reasonable and tweak compiler settings #1042
Conversation
Review by @granthenke and @gwenshap maybe? |
@@ -103,6 +103,12 @@ subprojects { | |||
|
|||
sourceCompatibility = 1.7 | |||
|
|||
compileJava { | |||
options.encoding = 'UTF-8' | |||
// Add unchecked once we drop support for Java 7 as @SuppressWarnings("unchecked") is too buggy in Java 7 |
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.
You mean "remove unchecked"?
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 meant adding unchecked
like so:
options.compilerArgs << "-Xlint:deprecation,unchecked"
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.
Got it.
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.
Got it.
LGTM. Maybe @ewencp could check if some unchecked casting in connect can be avoided? |
@guozhangwang I don't think they can, but happy for @ewencp to take a look. |
"-Xlog-reflective-calls", | ||
"-feature", | ||
"-language:postfixOps", | ||
"-language:implicitConversions", |
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.
Do we want to globally enable implicit conversions? Since we don't use them a lot (I think) and we are favoring JavaConverters vs JavaConversions we could just use import scala.language.implicitConversions
where necessary.
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 so, there isn't anything wrong with implicit conversions as extension methods IMO (implicit value classes give you that with no performance penalty). I can remove it if people feel strongly, but the language imports seem like useless boilerplate in most cases.
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 am okay either way. Just wanted to mention it.
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'm also ok with the import, but it is complete 180 turn on what we did before (only import the converters in the smallest possible scope to avoid any accidental conversion or something).
Perhaps a community discussion on the list about reversing this convention? I'm not suggesting a vote, but an announcement and give people chance to object if they feel strongly about it?
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.
Explained to Gwen that this change doesn't affect the JavaConverters/JavaConversions thing.
LGTM. Thanks for the cleanup @ijuma |
Ignored Kafka Streams on this iteration.
5667ff9
to
90d3322
Compare
Added a trivial additional commit that applies @granthenke's suggestion to reuse |
LGTM |
@SafeVarargs
annotation to fix warningsOnce we drop Java 7 and Scala 2.10, we can tweak the compiler settings further so that they warn us about more things.