Java 7 diamond operator and initialization with the derived class

Question

class A {}

class B extends A {}

class Holder<T> {

    T object;

    Holder(T object) {
        this.object = object;
    }
}

There's a Holder class to hold some object, created using generics. In the main(), when initialized using the diamond operator it doesn't compile (Java 7) with derived class passed to the Holder's constructor (required A / found B):

public static void main(String[] args) {    
    Holder<A> holder = new Holder<>(new B());        
}

But it compiles and works if the base type is specified in the right part:

public static void main(String[] args) {
    Holder<A> holder = new Holder<A>(new B());
}

Why? Doesn't diamond operator define the right part of the assignment with the same type parameters as the left side?

In Java 6 (i think, either 5 or 6), they added the feature in which you didnt need to specify the varags on the right side. You could leave the varags blank on the tight side `<>`, and itll compile fine. It depends what version of java youre using — Vince, May 07 '14 at 20:58
@LuiggiMendoza - You should turn your comment on the deleted answer into a new answer. It's the only thing on this page so far that properly addresses the question. — Dawood ibn Kareem, May 07 '14 at 21:03
@DavidWallace I remember to saw that problem discussed in a question here, but I cannot find the link =\ — Luiggi Mendoza, May 07 '14 at 21:04
@ElliottFrisch no because that Q/A is from 2010 where Java 8 was still in our hopes and dreams. It was from this year. — Luiggi Mendoza, May 07 '14 at 21:13

score 8 · Accepted Answer · edited May 23 '17 at 12:05

First observation:

Holder<B> h = new Holder<>(new B());

compiles both with Java 8 and Java 7, and both create a Holder<B> in that scenario. So using a <> with a constructor that takes arguments is fine.

However with:

Holder<A> h = new Holder<>(new B());

Java 7 first evaluates the right hand side, determines that it is a Holder<B> and gives a compile error because a Holder<B> can't be converted into a Holder<A>.
Java 8 goes one step further and infers that new Holder<A>(new B()) could actually work and does that auto-magically. This is thanks to a new feature called "target typing" - see the last section of the tutorial on type inference for an overview.

In more details, the improvement in Java 8 is due to the introduction of poly expressions (emphasis mine):

The type of a standalone expression can be determined entirely from the contents of the expression; in contrast, the type of a poly expression may be influenced by the expression's target type (§5 (Conversions and Contexts)).

This is a very powerful feature of Java 8 (Java 7 only offers standalone expressions that don't take the expression context into account).

A generic class instance creation is a poly expression and JLS #15.9 explains (emphasis mine):

A class instance creation expression is a poly expression (§15.2) if it uses the diamond form for type arguments to the class, and it appears in an assignment context or an invocation context (§5.2, §5.3). Otherwise, it is a standalone expression.

Because of that new rule, Java 8 allows you to use the second form above and automatically infers that new B() should be treated as an A (widening reference conversion) and that you meant to create a Holder<A> in that context.

@SamuelEdwinWard Java 7 makes no assumption: it considers the right hand side alone, determines it is a `Holder` and then tries to assign it to the left hand side but can't. Java 8 looks at the left hand side first, sees a `Holder`, tries to determine if the right hand side could fit in there and finds a way. It is a different methodology (the latter being smarter). — assylias, May 07 '14 at 21:57

Vishrant · Answer 2 · 2014-05-07T22:10:10.943

1

You will get

Type mismatch: cannot convert from Holder<B> to Holder<A>

The reason being,

new Holder<>(new B());

will call constructor Holder(T object) and it will set the type of <T> to B which does match to your left hand assignment Holder<A> holder.

If you will change left hand type to Holder<B> holder or Holder<? extends A> holder it will work fine even without giving type in right side <> bracket.

Remember B is a subclass of A, so A can hold the reference of B that is why

Holder<A> holder = new Holder<A>(new B());

OR

Holder<? extends A> holder = new Holder<>(new B());

is valid

edited May 07 '14 at 22:10

answered May 07 '14 at 20:58

Vishrant

15,456
11
71
120

2

AFAIK it is a bug in Java 7 compiler but it was fixed in Java 8. – Luiggi Mendoza May 07 '14 at 20:58
@LuiggiMendoza I don't think the question is regarding `<>` and bug in Java 7 – Vishrant May 07 '14 at 21:12
2

But that's the explanation... No matter how hard you try on Java 7, **it won't compile**, but it will in Java 8. – Luiggi Mendoza May 07 '14 at 21:14
@LuiggiMendoza i have posted the image, please check. – Vishrant May 07 '14 at 21:20
@LuiggiMendoza I don't think it is a bug in Java 7. – assylias May 07 '14 at 21:35
@assylias then why does it compile in Java 8? – Luiggi Mendoza May 07 '14 at 21:47
1

Java 7 is perfectly correct in rejecting it. It is not a compiler bug. Rather, the Java Language Specification was changed between Java 7 and Java 8 to include target typing. – David Conrad May 07 '14 at 21:47
@assylias looks like a gap in Java 7 that was fulfilled in Java 8. – Luiggi Mendoza May 07 '14 at 21:51
@luigi by that logic the absence of lambda expressions in java 7 could be considered a bug; fixed in java 8 – Richard Tingle May 07 '14 at 22:02

Java 7 diamond operator and initialization with the derived class

2 Answers2