title: Different generic behaviour when using lambda instead of explicit anonymous inner class
body: <h2>The context</h2>
  
  <p>I'm working on a project that is heavily dependent on generic types. One of its key components is the so-called <code>TypeToken</code>, which provides a way of representing generic types at runtime and applying some utility functions on them. To avoid Java's Type Erasure, I'm using the curly brackets notation (<code>{}</code>) to create an automatically generated subclass since this makes the type reifiable. </p>
  
  <h2>What <code>TypeToken</code> basically does</h2>
  
  <p>This is a strongly simplified version of <code>TypeToken</code> which is way more lenient than the original implementation. However, I'm using this approach so I can make sure that the real problem doesn't lie in one of those utility functions.</p>
  
  <pre><code>public class TypeToken&lt;T&gt; {
  
      private final Type type;
      private final Class&lt;T&gt; rawType;
  
      private final int hashCode;
  
  
      /* ==== Constructor ==== */
  
      @SuppressWarnings("unchecked")
      protected TypeToken() {
          ParameterizedType paramType = (ParameterizedType) this.getClass().getGenericSuperclass();
          this.type = paramType.getActualTypeArguments()[0];
  
          // ...
      } 
  </code></pre>
  
  <h2>When it works</h2>
  
  <p>Basically, this implementation works perfectly in almost every situation.
  It has no problem with handling most types. The following examples work perfectly:</p>
  
  <pre><code>TypeToken&lt;List&lt;String&gt;&gt; token = new TypeToken&lt;List&lt;String&gt;&gt;() {};
  TypeToken&lt;List&lt;? extends CharSequence&gt;&gt; token = new TypeToken&lt;List&lt;? extends CharSequence&gt;&gt;() {};
  </code></pre>
  
  <p>As it doesn't check the types, the implementation above allows every type that the compiler permits, including TypeVariables.</p>
  
  <pre><code>&lt;T&gt; void test() {
      TypeToken&lt;T[]&gt; token = new TypeToken&lt;T[]&gt;() {};
  }
  </code></pre>
  
  <p>In this case, <code>type</code> is a <code>GenericArrayType</code> holding a <code>TypeVariable</code> as its component type. This is perfectly fine.</p>
  
  <h2>The weird situation when using lambdas</h2>
  
  <p>However, when you initialize a <code>TypeToken</code> inside a lambda expression, things start to change. (The type variable comes from the <code>test</code> function above)</p>
  
  <pre><code>Supplier&lt;TypeToken&lt;T[]&gt;&gt; sup = () -&gt; new TypeToken&lt;T[]&gt;() {};
  </code></pre>
  
  <p>In this case, <code>type</code> is still a <code>GenericArrayType</code>, but it holds <code>null</code> as its component type.</p>
  
  <p>But if you're creating an anonymous inner class, things start to change again:</p>
  
  <pre><code>Supplier&lt;TypeToken&lt;T[]&gt;&gt; sup = new Supplier&lt;TypeToken&lt;T[]&gt;&gt;() {
          @Override
          public TypeToken&lt;T[]&gt; get() {
              return new TypeToken&lt;T[]&gt;() {};
          }
      };
  </code></pre>
  
  <p>In this case, the component type again holds the correct value (TypeVariable)</p>
  
  <h2>The resulting questions</h2>
  
  <ol>
  <li>What happens to the TypeVariable in the lambda-example? Why does the type inference not respect the generic type?</li>
  <li>What is the difference between the explicitly-declared and the implicitly-declared example? Is type inference the only difference?</li>
  <li>How can I fix this without using the boilerplate explicit declaration? This becomes especially important in unit testing since I want to check whether the constructor throws exceptions or not.</li>
  </ol>
  
  <p>To clarify it a bit: This is not a problem that's "relevant" for the program since I do NOT allow non-resolvable types at all, but it's still an interesting phenomenon I'd like to understand. </p>
  
  <h2>My research</h2>
  
  <h3>Update 1</h3>
  
  <p>Meanwhile, I've done some research on this topic. In the <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.2" rel="noreferrer">Java Language Specification §15.12.2.2</a> I've found an expression that might have something to do with it - "pertinent to applicability", mentioning "implicitly typed lambda expression" as an exception. Obviously, it's the incorrect chapter, but the expression is used in other places, including the chapter about type inference.</p>
  
  <p>But to be honest: I haven't really figured out yet what all of those operators like <code>:=</code> or <code>Fi0</code> mean what makes it really hard to understand it in detail. I'd be glad if someone could clarify this a bit and if this might be the explanation of the weird behavior.</p>
  
  <h3>Update 2</h3>
  
  <p>I've thought of that approach again and came to the conclusion, that even if the compiler would remove the type since it's not "pertinent to applicability", it doesn't justify to set the component type to <code>null</code> instead of the most generous type, Object. I cannot think of a single reason why the language designers decided to do so.</p>
  
  <h3>Update 3</h3>
  
  <p>I've just retested the same code with the latest version of Java (I used <code>8u191</code> before). To my regret, this hasn't changed anything, although Java's type inference has been improved...</p>
  
  <h3>Update 4</h3>
  
  <p>I've requested an entry in the offical Java Bug Database/Tracker a few days ago and it just got accepted. Since the developers who reviewed my report assigned the priority P4 to the bug, it might take a while until it'll be fixed. You can find the report <a href="https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8215328" rel="noreferrer">here</a>.</p>
  
  <p>A huge shoutout to Tom Hawtin - tackline for mentioning that this might be an essential bug in the Java SE itself. However, a report by Mike Strobel would probably be way more detailed than mine due to his impressive background knowledge. However, when I wrote the report, Strobel's answer wasn't yet available.</p>