abbreviated generic syntax

[Roedy Green]

In generics in Java 1.7 you can abbreviate

ArrayList<String> a = new ArrayList<String>( 100 );

as

ArrayList<String> a = new ArrayList<>( 100 );

Would any code have broken if you abbreviated like this instead:

ArrayList<String> a = new ArrayList( 100 );

If not, why the <>?
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Daniel Pitts]

In generics in Java 1.7 you can abbreviate

ArrayList<String> a = new ArrayList<String>( 100 );

as

ArrayList<String> a = new ArrayList<>( 100 );

Would any code have broken if you abbreviated like this instead:

ArrayList<String> a = new ArrayList( 100 );

If not, why the <>?

In theory, the difference is between a Raw Type, and the appropriate
Generic Type.

Put another way, ArrayList<?> isn't the same as ArrayList, and that
isn't the same as ArrayList<Object> either.

Since types java doesn't reify generic types, it is mainly of academic
interest, but it is a difference between the two.

 

[Barb Knox]

In generics in Java 1.7 you can abbreviate

ArrayList<String> a = new ArrayList<String>( 100 );

as

ArrayList<String> a = new ArrayList<>( 100 );

Would any code have broken if you abbreviated like this instead:

ArrayList<String> a = new ArrayList( 100 );

If not, why the <>?

I expect that a "new ArrayList(100)" returns an ArrayList of Objects.

--
---------------------------
| BBB b \ Barbara at LivingHistory stop co stop uk
| B B aa rrr b |
| BBB a a r bbb | Quidquid latine dictum sit,
| B B a a r b b | altum videtur.
| BBB aa a r bbb |
-----------------------------

 

[Arne Vajhoej]

I expect that a "new ArrayList(100)" returns an ArrayList of Objects.

It returns a raw ArrayList not an ArrayList<Object>.

The difference is small but it is there.

Arne

 

[Arne Vajhoej]

In generics in Java 1.7 you can abbreviate

ArrayList<String> a = new ArrayList<String>( 100 );

as

ArrayList<String> a = new ArrayList<>( 100 );

Would any code have broken if you abbreviated like this instead:

ArrayList<String> a = new ArrayList( 100 );

If not, why the <>?

Having:

new ArrayList( 100 )

return either raw ArrayList or ArrayList<X> depending on context
would be rather messy.

Arne

 

[Arne Vajhoej]

It returns a raw ArrayList not an ArrayList<Object>.

The difference is small but it is there.

I believe the classic example is:

import java.util.ArrayList;

public class RawVsObject {
public static void m1(ArrayList al) {
}
public static void m2(ArrayList<Object> al) {
}
public static void main(String[] args) {
ArrayList<String> al = null;
m1(al);
m2(al);
}
}

where the call to m1 is OK but the call to m2 gives a compiler
error.

Arne

 

[BGB]

In generics in Java 1.7 you can abbreviate

ArrayList<String> a = new ArrayList<String>( 100 );

as

ArrayList<String> a = new ArrayList<>( 100 );

Would any code have broken if you abbreviated like this instead:

ArrayList<String> a = new ArrayList( 100 );

If not, why the <>?

hell, why not:
ArrayList<String> a(100);
?...

and maybe also:
int[256] arr;
or:
int arr[256];

as a shorthand for:
int[] arr=new int[256];


granted, probably isn't going to happen...

 

[Lew]

In generics in Java 1.7 you can abbreviate
ArrayList<String> a = new ArrayList<String>( 100 );

as
ArrayList<String> a = new ArrayList<>( 100 );

Would any code have broken if you abbreviated like this instead:

ArrayList<String> a = new ArrayList( 100 );

Yes, legacy, pre-generic code.

If not, why the <>?

Backwards compatibility.

To avoid conflict with
http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.8

The diamond operator distinguishes the generics usage.

This is an example of why we read the JLS. It confers deep insight.

 

[Robert Klemme]

This is an example of why we read the JLS. It confers deep insight.

Sometimes when you say that it sounds as if you are talking about a holy
book. In a way the JLS *is* the bible of Java programming. Still, it
sounds strange...

Cheers

robert

 

[Lew]

Sometimes when you say that it sounds as if you are talking about a holy
book. In a way the JLS *is* the bible of Java programming. Still, it
sounds strange...

Notwithstanding your fanciful interpretation, it was an engineering statement.

"It sounds" is weasel-wording for "I made up my mind that it's".

 

[Roedy Green]

The diamond operator distinguishes the generics usage.

OK, that is obvious, but would it break any code?

 

[Andreas Leitgeb]

OK, that is obvious, but would it break any code?

I'm not taking the time to think it all through to the end,
but "fwiw":

To see any technical difference between the two patterns:
Base<Type> b = new Sub<>();
and
Base<Type> b = new Sub();

You might want to consider different subclasses of some class,
where one is itself generic and the other is not:
interface Base<T> { ... }
class Sub1<T> implements Base<T> { ... }
class Sub2 implements Base<String> { ... }

Most likely(*), it is currently *not* legal to write:
Base<String> b = new Sub2<>();

So, the compiler probably shouldn't *always* assume the <>
to a pattern like: Base<Type> b = new SubClass();

In how far it would be always possible for the compiler to
check the referenced class first (to see if it is generic
and if so then just assume the diamond), I can't tell.

PS:
*: I did not care enough to check the JLS or even try it.

 

[Joshua Cranmer ðŸ§]

OK, that is obvious, but would it break any code?

In the Java typing system, a generic type that is used without generics
(aka a raw type) is a very distinct type. "List" is not "List<?>" nor is
it "List<Object>" nor any other value that you stick in those brackets
[1]. If you didn't have the diamond operator, it would be ambiguous as
to whether inferred type arguments or the actual raw type was desired.
Imagine scenarios like:

Collections.singletonList(new List());

[1] This is *really* annoying because the type of List.class is
Class<List> (a rare type), not Class<List<?>>. If you thought raw types
were hard to use, rare types pretty much require you to sprinkle your
code with @SuppressWarnings.

 

[Arne Vajhoej]

OK, that is obvious, but would it break any code?

I can not think of any.

But having a RHS expression which changes semantics after LHS is
not the Java way.

Arne

 

[BGB]

I can not think of any.

But having a RHS expression which changes semantics after LHS is
not the Java way.

yep, pretty much.


although taking the destination type into account could help with things
like preserving precision by promoting types early, or help avoid
unnecessary warnings/errors in a few other cases (for example, lessening
the need for suffixes on numerical constants, ...), it is less certain
in other cases, namely where the interpretation could have a potentially
significant influence on language semantics.