5

So I have below line of code in my file 

List<String> nameList = new ArrayList<String>();

Now each time I run sonar scans it shows an error in above line saying I should use diamond operator instead. Now I understand that from Java7 compiler will automatically detect and supply the type of objects for ArrayList but my question is there a harm if I do it myself while declaring the class ?

Here is the rule link from Sonar website. I really don't understand the example they are supplying with this rule.

Is there any performance, efficiency or any other type of gain in changing the code to what Sonar is suggesting ?

Amit
  • 13,134
  • 17
  • 77
  • 148
  • You are simply wasting keystrokes. That's the only performance issue. – Andy Turner Aug 31 '18 at 15:09
  • There shouldn't be hard rules about that. But one can argue that the diamond operator makes it easier to maintain if the concrete type would otherwise be repeated (you'd have just the type to change). – ernest_k Aug 31 '18 at 15:10
  • I don't think it has any effect on performance or whatever, it's just a shorter declaration. Note that the severity is set to minor, so nothing to worry about. – Bouke Aug 31 '18 at 15:16
  • 2
    Also note that generics is only in source and not in bytecode, which means it has nothing to do with performance and efficiency. – Bhesh Gurung Aug 31 '18 at 15:32

3 Answers3

10

Less you have helpless and duplicate code and more the code is readable and maintainable.

List<String> nameList = new ArrayList<String>();

or 

List<String> nameList = new ArrayList<>();

Ok, not a lot of differences.

But suppose now that you have to change the generic: String by Integer, with the first way you have to do two modifications: 

List<Integer> nameList = new ArrayList<Integer>();
      ^------               -------------^

Really not nice.

With the diamond a single one is required : 

List<Integer> nameList = new ArrayList<>();
      ^---

But take another example : 

Map<String, List<Integer>> map = new HashMap<String, List<Integer>>();

or

Map<String, List<Integer>> map = new HashMap<>();

It makes things clearer.

In an application, you generally declare and instantiate tons of collections and generic classes. Refactoring it is really cheap. So just do it.

lealceldeiro
  • 14,342
  • 6
  • 49
  • 80
davidxxx
  • 125,838
  • 23
  • 214
  • 215
9

is there a harm if I do it myself while declaring the class ?

No, there is not any harm in doing it this way, except for the extra verbosity added to the code. From the same rule link we can read that

Java 7 introduced the diamond operator (<>) to reduce the verbosity of generics code

Is there any performance, efficiency or any other type of gain in changing the code to what Sonar is suggesting ?

Except for the fact that you (and your team) will have a less verbose code, no, there is not.

Further readings:

lealceldeiro
  • 14,342
  • 6
  • 49
  • 80
  • I have come to an obscure case where a a field is initialized in a method. So, unless you go and see the field declaration it would be not obvious what the diamond specialization should be. One could argue that initializing a field should be done close to the declaration but that would be besides the point – Dr Phil Jul 29 '20 at 19:55
2

The whole point behind this rule is: In java 7 the compiler got the ability to infer the type for the constructor from the type itself.

Why should you omit the generic type in the constructor?

2 things:

  • it is more verbose to specify the type twice
  • you do not need to change the type for the generic twice if you decide to change the collection.

Is it harmful to leave it as it is? Not really. But it's always better to have a consistent code style in your team. So if you team uses sonar for codestyle checking you should conform to it for the sake of consistency.

Markus Mauksch
  • 397
  • 1
  • 9