Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

abbreviated generic syntax

21 views
Skip to first unread message

Roedy Green

unread,
Feb 17, 2013, 11:26:43 PM2/17/13
to
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

unread,
Feb 18, 2013, 4:02:31 AM2/18/13
to
On 2/17/13 8:26 PM, Roedy Green wrote:
> 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

unread,
Feb 18, 2013, 4:41:00 AM2/18/13
to
In article <0h93i8pcopf17145f...@4ax.com>,
Roedy Green <see_w...@mindprod.com.invalid> wrote:

> 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 |
-----------------------------

Donkey Hottie

unread,
Feb 18, 2013, 5:58:22 AM2/18/13
to
18.02.2013 11:41, Barb Knox kirjoitti:
> In article <0h93i8pcopf17145f...@4ax.com>,
> Roedy Green <see_w...@mindprod.com.invalid> wrote:
>
>> 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.
>

It has an storage arrangement for 100 object references (and Strings ARE
Objects), but it does not allocate any Objecs nor Strings in that
initialization.

--

You will pass away very quickly.

Arne Vajhoej

unread,
Feb 18, 2013, 7:20:34 AM2/18/13
to
On 2/18/2013 4:41 AM, Barb Knox wrote:
> In article <0h93i8pcopf17145f...@4ax.com>,
> Roedy Green <see_w...@mindprod.com.invalid> wrote:
>
>> 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.

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

The difference is small but it is there.

Arne


Arne Vajhoej

unread,
Feb 18, 2013, 7:23:38 AM2/18/13
to
On 2/17/2013 11:26 PM, Roedy Green wrote:
> 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

unread,
Feb 18, 2013, 7:27:31 AM2/18/13
to
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


Chris Uppal

unread,
Feb 18, 2013, 2:33:52 PM2/18/13
to
Roedy Green wrote:
> 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 );

It would greatly irritate those who think that the "new" generics stuff is of
negative benefit, since now the compiler would be adding generics in /even when
I hadn't asked for it/.

-- chris


BGB

unread,
Feb 18, 2013, 2:46:47 PM2/18/13
to
On 2/17/2013 10:26 PM, Roedy Green wrote:
> 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

unread,
Feb 18, 2013, 3:29:53 PM2/18/13
to Roedy Green
On Sunday, February 17, 2013 8:26:43 PM UTC-8, Roedy Green wrote:
> 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.

--
Lew

Robert Klemme

unread,
Feb 18, 2013, 4:49:13 PM2/18/13
to
On 18.02.2013 21:29, Lew wrote:

> 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

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Lew

unread,
Feb 18, 2013, 4:51:40 PM2/18/13
to
Robert Klemme wrote:
> Lew wrote:
>> 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...

Notwithstanding your fanciful interpretation, it was an engineering statement.

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

--
Lew

Roedy Green

unread,
Feb 18, 2013, 6:35:33 PM2/18/13
to
On Mon, 18 Feb 2013 12:29:53 -0800 (PST), Lew <lewb...@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>The diamond operator distinguishes the generics usage.

OK, that is obvious, but would it break any code?
--
Roedy Green Canadian Mind Products http://mindprod.com
The generation of random numbers is too important to be left to chance.
~ Robert R. Coveyou (born: 1915 died: 1996-02-19 at age: 80)

lipska the kat

unread,
Feb 19, 2013, 3:56:11 AM2/19/13
to
On 18/02/13 23:35, Roedy Green wrote:
> On Mon, 18 Feb 2013 12:29:53 -0800 (PST), Lew<lewb...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> The diamond operator distinguishes the generics usage.
>
> OK, that is obvious, but would it break any code?

Just to recap

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

is quite clear

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

means you can do this and it compiles (1.6 and 1.7)

2. ArrayList<String> c = new ArrayList( 100 );
c.add(new String("foo"));

but you will get a runtime exception if you try to do
Integer ops on the String

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

uses the 1.7 <> operator to allow the compiler to infer the type at
compile time from the type of the LHS, it's shorthand to allow you to
avoid having to type the generic params twice.

Given that generics is all about compile time type checking then I can't
see anything breaking.

http://docs.oracle.com/javase/1.5.0/docs/guide/language/index.html

lipska

--
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

lipska the kat

unread,
Feb 19, 2013, 7:30:31 AM2/19/13
to
On 19/02/13 08:56, lipska the kat wrote:

Oooooo I got that wrong of course, that should be

2. ArrayList<Integer> c = new ArrayList( 100 );
c.add(new String("foo"));

Doesn't compile

It's been a long morning

Andreas Leitgeb

unread,
Feb 19, 2013, 11:21:12 AM2/19/13
to
Roedy Green <see_w...@mindprod.com.invalid> wrote:
> On Mon, 18 Feb 2013 12:29:53 -0800 (PST), Lew <lewb...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>> The diamond operator distinguishes the generics usage.
> 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 🐧

unread,
Feb 19, 2013, 12:38:46 PM2/19/13
to
On 2/18/2013 5:35 PM, Roedy Green wrote:
> On Mon, 18 Feb 2013 12:29:53 -0800 (PST), Lew <lewb...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> The diamond operator distinguishes the generics usage.
>
> 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.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Arne Vajhoej

unread,
Feb 19, 2013, 12:45:42 PM2/19/13
to
On 2/18/2013 6:35 PM, Roedy Green wrote:
> On Mon, 18 Feb 2013 12:29:53 -0800 (PST), Lew <lewb...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>> The diamond operator distinguishes the generics usage.
>
> 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

unread,
Feb 19, 2013, 4:20:01 PM2/19/13
to
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.


0 new messages