JDK-8055778 : 4.3: Clarify status of unnamed types
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 8
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-08-21
  • Updated: 2016-09-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorUnresolved
Related Reports
Relates :  
Description
Capture variables, intersection types, and the null type are "unnamed", meaning they cannot be referenced syntactically; but they are still types.  JLS 4.1 and 4.3 do not mention them in the grammar rules.  Of course, we cannot simply add them to the grammar rules, because then they would be valid syntax.  Instead, we need a concept of "reference type" that is broader than just the set of valid syntax, ReferenceType.

Intersection types are the simplest case: clearly, they are reference types.  But they are not mentioned at all in section 4.3.

Capture variables are "just" type variables, per 5.1.10, but they have unique properties that go unmentioned in 4.4 (no declaration, unclear scope, a lower bound).  So they should either be defined as unique entities, or 4.4 should be general enough to describe them as well.

The status of the null type is vague.  4 (intro) and 4.1 can be read to treat is as a third kind of type (in addition to primitive and reference) or as a kind of reference type.  It makes the most sense to treat it as a reference type, since all values are either primitives or references, and "null type" describes a subset of references.  In that case, it should be described as an unnamed reference type in 4.3.

Also note that intersection types and capture variables can appear as part of a class type, interface type, or array type, due to substitution.  So types like 'List<Foo & Bar>' are _also_ unnamed types.  Some class types are not ClassTypes; some interface types are not InterfaceTypes; some array types are not ArrayTypes.

(The null type can never appear as part of another type, because of how it is treated by type inference.)
Comments
If we want to call the null type a reference type, care should be taken in the handling of widening reference conversions (5.1.4) and and conversions from the null type (5.2, 5.3, etc.) It should be an error to convert from null to 'int'. See JDK-8166326.
20-09-2016

Another case to consider: anonymous class types. The type of an anonymous class instance creation expression is that class type (see 15.9.3), but no syntax can be used to name this class.
26-08-2014

I notice that the organization of Chapter 4 is a bit of a mess. 4.2 neatly contains the full enumeration of primitive types, while reference types are spread out over 4.3, 4.4, 4.5, 4.8, and 4.9, plus 10.1. This bug may be an opportunity for some incremental cleanup. (Or not -- legacy concerns may override organizational problems.)
21-08-2014

Another way to approach this would be to define the syntax inclusively, but then have a non-syntactic check that reports an error when encountering an unnamed type.
21-08-2014