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

A2:Je_3_Resolve_SamePackageAndClassName

30 views
Skip to first unread message

Kwon Bo Kyun

unread,
Mar 5, 2014, 2:23:16 AM3/5/14
to
can anyone tell me why this is invalid and which part of JLS covers it?

Ondřej Lhoták

unread,
Mar 5, 2014, 5:20:25 PM3/5/14
to
On Tue, Mar 04, 2014 at 11:23:16PM -0800, Kwon Bo Kyun wrote:
> can anyone tell me why this is invalid and which part of JLS covers it?

The name in the instantiation expression
new Je_3_Resolve_SamePackageAndClassName.Je_3_Resolve_SamePackageAndClassName()
is Je_3_Resolve_SamePackageAndClassName.Je_3_Resolve_SamePackageAndClassName

According to JLS 6.5, the first Je_3_Resolve_SamePackageAndClassName
(before the dot) is an AmbiguousName.

Applying JLS 6.5.2 to that simple AmbiguousName
Je_3_Resolve_SamePackageAndClassName, the first bullet applies.
Under that bullet, the third bullet applies ("Otherwise, if a type of
that name is declared in the compilation unit (§7.3) containing the
Identifier, either by a single-type-import declaration (§7.5.1) or by a
top level class (§8) or interface type declaration (§9), then the
AmbiguousName is reclassified as a TypeName.") because the name
is a top level class.

Therefore, the full name
Je_3_Resolve_SamePackageAndClassName.Je_3_Resolve_SamePackageAndClassName
refers to a type called Je_3_Resolve_SamePackageAndClassName inside the
type (NOT INSIDE THE PACKAGE) named
Je_3_Resolve_SamePackageAndClassName. However, that type does not
contain an inner type with that name (and anyway, Joos does not allow
types to contain types). Therefore, resolution of the name
Je_3_Resolve_SamePackageAndClassName.Je_3_Resolve_SamePackageAndClassName
fails.

Try compiling the same class with javac.

0 new messages