loading...

Effective Java! Elminate Unchecked Warnings

kylec32 profile image Kyle Carter ・2 min read

Effective Java Review (32 Part Series)

1) Effective Java Tuesday! Let's Consider Static Factory Methods 2) Effective Java Tuesday! The Builder Pattern! 3 ... 30 3) Effective Java Tuesday! Singletons! 4) Effective Java Tuesday! Utility Classes! 5) Effective Java Tuesday! Prefer Dependency Injection! 6) Effective Java Tuesday! Avoid Creating Unnecessary Objects! 7) Effective Java Tuesday! Don't Leak Object References! 8) Effective Java Tuesday! Avoid Finalizers and Cleaners! 9) Effective Java Tuesday! Prefer try-with-resources 10) Effective Java Tuesday! Obey the `equals` contract 11) Effective Java Tuesday! Obey the `hashCode` contract 12) Effective Java Tuesday! Override `toString` 13) Effective Java Tuesday! Override `clone` judiciously 14) Effective Java Tuesday! Consider Implementing `Comparable` 15) Effective Java Tuesday! Minimize the Accessibility of Classes and Member 16) Effective Java Tuesday! In Public Classes, Use Accessors, Not Public Fields 17) Effective Java Tuesday! Minimize Mutability 18) Effective Java Tuesday! Favor Composition Over Inheritance 19) Effective Java Tuesday! Design and Document Classes for Inheritance or Else Prohibit It. 20) Effective Java Tuesday! Prefer Interfaces to Abstract Classes 21) Effective Java! Design Interfaces for Posterity 22) Effective Java! Use Interfaces Only to Define Types 23) Effective Java! Prefer Class Hierarchies to Tagged Classes 24) Effective Java! Favor Static Members Classes over Non-Static 25) Effective Java! Limit Source Files to a Single Top-Level Class 26) Effective Java! Don't Use Raw Types 27) Effective Java! Elminate Unchecked Warnings 28) Effective Java! Prefer Lists to Array 29) Effective Java! Favor Generic Types 30) Effective Java! Favor Generic Methods 31) Effective Java! Use Bounded Wildcards to Increase API Flexibility 32) Effective Java! Combine Generics and Varargs Judiciously

As you start to use more and more generics you often will run into more unchecked warnings. Because Java has backwards compatability via raw types, as discussed in our previous chapter review, the compiler will not prevent us from writing type unsafe code. Even though it won't prevent us from compiling it will give us warnings. It is these warnings that we are focusing on in this chapter.

As far as warnings go there are some that are harder to address than others. Some warnings simply require us to add the type to the declaration. For example the following code will throw an unchecked warning:

Set<String> myStrings = HashSet();

We can fix it as simply as:

Set<String> myStrings = HashSet<>();

We don't even need to list the type on the right-hand-side in this case as the diamond operator (<>) will cause the compiler to infer the type. Some other cases may not be as easy to remove the unchecked exceptions but if we can get rid of all the unchecked exceptions we can gain confidence that we won't have a ClassCastException.

So what if we find ourselves in a situation where we either can't get rid of the warning or the warning is showing up even though we know there is no risk of a class cast exception? If we have no other options the next step would be to annotate the unchecked usage with the @SuppressWarnings("unchecked") annotation. This, as the name suggests, will suppress the warning so that we don't get buried in warnings and so we can give the proper attention to future unchecked warnings. So what should we keep in mind when suppressing these warnings?

  • Only suppress warnings for locations you know are already type safe.
  • Put the suppress warnings annotation on smallest scope you can to accomplish the desired suppression.
  • Provide a comment for future developers of why the suppress warnings annotation is there and why it is still safe.

That's what it comes down to. Remove all warnings (honestly all warnings not just the unchecked ones that we are focusing in this chapter) and for all places where you can't fix the warnings, suppress the warnings.

Effective Java Review (32 Part Series)

1) Effective Java Tuesday! Let's Consider Static Factory Methods 2) Effective Java Tuesday! The Builder Pattern! 3 ... 30 3) Effective Java Tuesday! Singletons! 4) Effective Java Tuesday! Utility Classes! 5) Effective Java Tuesday! Prefer Dependency Injection! 6) Effective Java Tuesday! Avoid Creating Unnecessary Objects! 7) Effective Java Tuesday! Don't Leak Object References! 8) Effective Java Tuesday! Avoid Finalizers and Cleaners! 9) Effective Java Tuesday! Prefer try-with-resources 10) Effective Java Tuesday! Obey the `equals` contract 11) Effective Java Tuesday! Obey the `hashCode` contract 12) Effective Java Tuesday! Override `toString` 13) Effective Java Tuesday! Override `clone` judiciously 14) Effective Java Tuesday! Consider Implementing `Comparable` 15) Effective Java Tuesday! Minimize the Accessibility of Classes and Member 16) Effective Java Tuesday! In Public Classes, Use Accessors, Not Public Fields 17) Effective Java Tuesday! Minimize Mutability 18) Effective Java Tuesday! Favor Composition Over Inheritance 19) Effective Java Tuesday! Design and Document Classes for Inheritance or Else Prohibit It. 20) Effective Java Tuesday! Prefer Interfaces to Abstract Classes 21) Effective Java! Design Interfaces for Posterity 22) Effective Java! Use Interfaces Only to Define Types 23) Effective Java! Prefer Class Hierarchies to Tagged Classes 24) Effective Java! Favor Static Members Classes over Non-Static 25) Effective Java! Limit Source Files to a Single Top-Level Class 26) Effective Java! Don't Use Raw Types 27) Effective Java! Elminate Unchecked Warnings 28) Effective Java! Prefer Lists to Array 29) Effective Java! Favor Generic Types 30) Effective Java! Favor Generic Methods 31) Effective Java! Use Bounded Wildcards to Increase API Flexibility 32) Effective Java! Combine Generics and Varargs Judiciously

Posted on Jun 2 by:

kylec32 profile

Kyle Carter

@kylec32

Backend Architect at MasterControl

Discussion

markdown guide