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

KAFKA-3375; Suppress deprecated warnings where reasonable and tweak compiler settings #1042

Closed

Conversation

ijuma
Copy link
Member

@ijuma ijuma commented Mar 10, 2016

  • Fix and suppress number of unchecked warnings (except for Kafka Streams)
  • Add @SafeVarargs annotation to fix warnings
  • Suppress unfixable deprecation warnings
  • Replace deprecated by non-deprecated usage where possible
  • Avoid reflective calls via structural types in Scala
  • Tweak compiler settings for scalac and javac

Once we drop Java 7 and Scala 2.10, we can tweak the compiler settings further so that they warn us about more things.

@ijuma
Copy link
Member Author

ijuma commented Mar 10, 2016

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
Copy link
Contributor

Choose a reason for hiding this comment

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

You mean "remove unchecked"?

Copy link
Member Author

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"

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it.

@guozhangwang
Copy link
Contributor

LGTM. Maybe @ewencp could check if some unchecked casting in connect can be avoided?

@ijuma
Copy link
Member Author

ijuma commented Mar 11, 2016

@guozhangwang I don't think they can, but happy for @ewencp to take a look.

"-Xlog-reflective-calls",
"-feature",
"-language:postfixOps",
"-language:implicitConversions",
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Contributor

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?

Copy link
Member Author

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.

@granthenke
Copy link
Member

LGTM. Thanks for the cleanup @ijuma

@ijuma ijuma force-pushed the kafka-3375-suppress-depreccated-tweak-compiler branch from 5667ff9 to 90d3322 Compare March 11, 2016 21:32
@ijuma
Copy link
Member Author

ijuma commented Mar 11, 2016

Added a trivial additional commit that applies @granthenke's suggestion to reuse sourceCompatibility.

@gwenshap
Copy link
Contributor

LGTM

@asfgit asfgit closed this in 241c3eb Mar 15, 2016
@ijuma ijuma deleted the kafka-3375-suppress-depreccated-tweak-compiler branch April 5, 2016 09:17
mumrah pushed a commit to mumrah/kafka that referenced this pull request Aug 14, 2024
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.

4 participants