1

In JDK 8, compiler suggests to omit this

ArrayList<String> someList = new ArrayList<String>();

To this

ArrayList<String> someList = new ArrayList<>();

Marking the second String as redundant.

However, compiler does not complain even if the diamond operator is completely omitted like this

ArrayList<String> someList = new ArrayList();

And this does not seem to create any issues during runtime. Are there any concrete differences between having a diamond operator and not having? If anyone could elaborate I'd really appreciate it.

tankucukoglu
  • 455
  • 6
  • 20
  • Mmm, I think this is already answered [here](http://www.javaworld.com/article/2074080/core-java/jdk-7--the-diamond-operator.html) and [here](http://stackoverflow.com/questions/4166966/what-is-the-point-of-the-diamond-operator-in-java-7) – Joaquin Iurchuk Jul 03 '15 at 14:03
  • I was explicitly looking for java 8 resources thinking it was a java 8 specific thing. Thanks for providing these! – tankucukoglu Jul 03 '15 at 14:16
  • You should have gotten an _unchecked conversion_ warning at compile time to indicate you were doing something that might not be safe. – Brian Goetz Jul 03 '15 at 14:51
  • Well I actually did not and that's what initially surprised me. I'm using NetBeans and I barely noticed that line was missing diamond operators. – tankucukoglu Jul 03 '15 at 14:59
  • Perhaps you've adjusted your warnings/inspection profile in NetBeans? Most IDEs will flag this using their default settings; certainly javac will issue an unchecked warning in your build. – Brian Goetz Jul 03 '15 at 15:46
  • You could be right, I'll check my warning settings... – tankucukoglu Jul 03 '15 at 16:08

2 Answers2

4

In JDK 8, compiler suggests to omit this

ArrayList<String> someList = new ArrayList<String>();

To this

ArrayList<String> someList = new ArrayList<>();

The diamond <> operator was introduced in Java 7 because it is easy to infer the type and it removes the need to repeat the type.

However, compiler does not complain even if the diamond operator is completely omitted like this

ArrayList<String> someList = new ArrayList();

Here you are using Raw Types which is discouraged.

For backwards compatability, at runtime all Collections are treated as containing Object. Generics are used to establish a contract at compile time which says every time a put something into or take something out of this collection it must be of type xxx.

None of the generics details remain at run time (called Type Erasure) because generics is a compile time only feature of Java.

This code is therefore actually perfectly acceptable (although discouraged). However, if you go as far as:

ArrayList someList = new ArrayList();

you will start finding very strange and unexpected things going on.

OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
  • Professor at my college discouraged us to use the new short form (that is, `= new ArrayList<>()`) and instead use `= new ArrayList()` because of the way Java handles this *new feature*. He said that using the former is way less efficient than latter, so in his classes we use the long form. Is he right? – Joaquin Iurchuk Jul 03 '15 at 14:36
  • 1
    @joaquin - No he/she is not. – OldCurmudgeon Jul 03 '15 at 14:37
  • He said that with this new short form what really does Java is instantiate the Object class and then makes a cast. He called it *a dirty process*. – Joaquin Iurchuk Jul 03 '15 at 14:39
  • 2
    @joaquin - I can assure you either you have misunderstood what he said or he is wrong. There is **no** extra instantiation going on. Java generics is a **compile time only** feature and therefore cannot cause any extra cost at run-time. – OldCurmudgeon Jul 03 '15 at 14:42
  • Great! I'll talk back with him. Maybe I misunderstood him or maybe he misunderstood this Java's new feature. Thanks for your answer! – Joaquin Iurchuk Jul 03 '15 at 14:44
  • 1
    @joaquin - Please be sure to do so much more politely than I have stated here. :) Have a look [here](http://java.dzone.com/announcements/java-7-do-we-really-need) for a cogent discussion on the question. – OldCurmudgeon Jul 03 '15 at 14:46
  • Yes, I'll do! At least now I feel more encouraged to talk with him. Thanks for your time and for the link! I'll check it out! – Joaquin Iurchuk Jul 03 '15 at 14:50
  • 2
    @joaquin Explain to your professor that the "diamond" expression simply uses compile-time type inference to choose the correct instantiation -- which is then erased at runtime anyway. There's absolutely no performance issue here. (Now, perhaps he likes the old way because its more explicit, or just because he likes the old way.) – Brian Goetz Jul 03 '15 at 15:48
  • @BrianGoetz Professors at my college are very conservative, maybe that's the answer. But, instead of telling me that, they said me that is inefficient technique, which is wrong. – Joaquin Iurchuk Jul 03 '15 at 15:55
  • 1
    @joaquin - You won't get a better authority than [Brian Goetz](http://www.oracle.com/us/technologies/java/briangoetzchief-188795.html). – OldCurmudgeon Jul 03 '15 at 16:05
  • Oh, I didn't notice who Brian Goetz is! It's a Java Architect at Oracle. Can't believe I didn't check his profile before answer him. Thanks, @BrianGoetz for your answer and your time. I feel more encouraged than ever to talk with my professor. Thanks both of you. – Joaquin Iurchuk Jul 03 '15 at 16:09
  • 1
    @joaquin Regarding _dirty process_, he's sort of correct that this is how generics work across the board -- dirtiness and all -- but he's dead wrong about `new Foo<>()` vs `new Foo()`. Perhaps he needs to go back for some Java training... – Brian Goetz Jul 03 '15 at 16:22
  • @BrianGoetz I remember some exam in which I wrote `Map> map = new MyMap<>()` and the person who corrected it striked out that line and noted in a margin *the missing part*: `= new MyMap>()`. When I asked him why, he told me that about efficiency. Thanks, Brian. As OldCurmudgeon said: "No better authority than you". – Joaquin Iurchuk Jul 03 '15 at 16:30
0

These are ONLY compiler warnings.

It looks like the warning suggesting dropping the type to use the diamond operator is turned on. The warning about missing type/diamond operator is not turned on.

In any case the complied code is identical.

Essentially these warning are there to help produce 'safer' code, i.e. easier to read.

Brett Walker
  • 3,566
  • 1
  • 18
  • 36