41

Consider this Java code which attempts to instantiate some Lists:

List<String> list1 = new ArrayList<String>();
List<String> list2 = new ArrayList<>();
List<String> list3 = new ArrayList<String>() { };
List<String> list4 = new ArrayList<>() { };
List<String> list5 = new ArrayList<Integer>() { };

list1 and list2 are straightforward; list2 uses the new diamond operator in Java 7 to reduce unnecessary repetition of the type parameters.

list3 is a variation on list1 using an anonymous class, potentially to override some methods of ArrayList.

list4 attempts to use the diamond operator, similar to list2, but this is a compile error, with the message '<>' cannot be used with anonymous classes.

list5 produces an error that proves the compiler knows what type is actually needed. The error message is Type mismatch: cannot convert from new ArrayList<Integer>(){} to List<String>

So, with the declaration of list4, why can't the diamond operator be used with anonymous classes? There is a similar question here with an accepted answer that contains the following explanation from JSR-334:

Using diamond with anonymous inner classes is not supported since doing so in general would require extensions to the class file signature attribute to represent non-denotable types, a de facto JVM change.

I need some help understanding that reasoning. Why would an explicit type versus the identical and apparently easily inferred type require any difference in the resulting class file? What difficult use case would be covered by "doing so in general"?

What is the underlying reason for this?

Community
  • 1
  • 1
Dave Hartnoll
  • 1,144
  • 11
  • 21
  • 1
    This is not a duplicate of that specific question. I referenced a similar question, but need an explanation for the answer (or a better answer). – Dave Hartnoll Mar 05 '14 at 14:36
  • The answer you've linked to gives a 'best guess' at what the paragraph you've quoted means. What don't you understand? Are you wanting a more solid answer? – Radiodef Mar 05 '14 at 14:39
  • http://stackoverflow.com/questions/9512526/java-7-diamond-operator-why-was-it-difficult-to-implement?rq=1 some slight explanation – RMachnik Mar 05 '14 at 14:40
  • Thanks @Rafik991, I read that answer too, but It didn't really help with understanding any odd use cases. – Dave Hartnoll Mar 05 '14 at 14:43
  • @Radiodef The best guess in the linked answer doesn't really cover why the compiler cannot (or chooses not to) infer the correct type. Once the type is known, the generated class ought to be the same. Or maybe not - in which case any additional explanation would help. – Dave Hartnoll Mar 05 '14 at 14:49
  • http://stackoverflow.com/questions/13821586/why-cant-diamond-infer-types-on-anonymous-inner-classes – ZhongYu Jun 18 '14 at 06:33

5 Answers5

24

This was discussed on the "Project Coin" mailing list. In substance (emphasis mine):

Internally, a Java compiler operates over a richer set of types than those that can be written down explicitly in a Java program. The compiler-internal types which cannot be written in a Java program are called non-denotable types. Non-denotable types can occur as the result of the inference used by diamond. Therefore, using diamond with anonymous inner classes is not supported since doing so in general would require extensions to the class file signature attribute to represent non-denotable types, a de facto JVM change. It is feasible that future platform versions could allow use of diamond when creating an anonymous inner class as long as the inferred type was denotable.

Note that it is not supported in Java 8 either but will be included as a new feature in Java 9 (Item 3 of "Milling Project Coin").

assylias
  • 321,522
  • 82
  • 660
  • 783
  • 2
    Many thanks for this answer. The mailing list you linked also pointed to http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6894753 which contains a much deeper analysis and also an example of a 'difficult' class. In short, it seems the reason inference doesn't work with anonymous classes is that the work to support it would be disproportionate. – Dave Hartnoll Mar 05 '14 at 15:26
  • 2
    The solution for JDK 9 is as simple as one can imagine: just allow it only for denotable types. The big irony is that the problem they wanted to avoid, is already there. Consider `public class Foo { Foo(T t) {} public static void main(String... arg) { System.out.println( new Foo<>("".getClass()).new Inner() {} .getClass().getGenericSuperclass()); } class Inner {} }`. This captures a non-denotable type that can't be expressed in bytecode. Prior to JDK 11, it will produce invalid bytecode, starting with JDK 11, it produces the compiler error "illegal signature attribute" without explanation. – Holger Sep 13 '20 at 15:42
2

You can use diamond opeator in Java9

MyHandler<Integer> intHandler = new MyHandler<>(1) {

        @Override
        public void handle() {
            // handling code...
        }
    };

    MyHandler<? extends Integer> intHandler1 = new MyHandler<>(10) {

        @Override
        void handle() {
            // handling code...
        }
    };

    MyHandler<?> handler = new MyHandler<>("One hundred") {

        @Override
        void handle() {
            // handling code...
        }
    };
}
Durgpal Singh
  • 11,481
  • 4
  • 37
  • 49
2

You can use it in java 9 Example Diamond operator

 MyHandler<Integer> intHandler = new MyHandler<>(1) {

        @Override
        public void handle() {
            // handling code...
        }
 };
jitendra varshney
  • 3,484
  • 1
  • 21
  • 31
1

From Java 10, you can do easily with var, the compiler will take care of the Type inference.

var list1 = new ArrayList();
var list2 = new ArrayList<String>();
var list3 = new ArrayList<String>() { };
var list4 = new ArrayList<>() { };
var list5 = new ArrayList<Integer>() { };
hoan
  • 1,058
  • 8
  • 13
0

From Java 9, diamond operator <> can be used with anonymous classes. See here.

user2485429
  • 567
  • 8
  • 7