Community
Participate
Working Groups
Build ID: I20090313-0100 Steps To Reproduce: 1. Create a /single file/ with two classes; one with a third class nested, and the second with an (illegal) reference to the nested class: class A { class B { } } class C { B d; // B cannot be resolved to a type } 2. Quick fix the compile error. One of the options is "Import B (A)", which does nothing at all. Not affected by not being in the default package. -- java.version=1.6.0_13 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws win32 -arch x86_64
Moving to JDT/UI
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Still a problem but very minor as default packages are discouraged.
The behaviour has changed in the meantime. The quick fix now, instead of not doing anything, does insert an import statement: import Test.B; but this import statement is invalid and results in the error "The import Test cannot be resolved". Section 7.5.1 of the JLS in its current form (SE 16) (https://docs.oracle.com/javase/specs/jls/se16/html/jls-7.html#jls-7.5.1) says: "The class or interface must be either a member of a named package, or a member of a class or interface whose outermost lexically enclosing class or interface declaration (§8.1.3) is a member of a named package, or a compile-time error occurs." Incidentally, the JLS has changed several times in this respect since the bug was first reported. (What follows is mostly of historical interest.) At the time (2009), the JLS for SE 6 (https://docs.oracle.com/javase/specs/jls/se6/html/packages.html#7.5.1) didn't seem to prohibit such an import from an unnamed package. In the JLS for SE 7, this sentence was added to Section 7.5 (https://docs.oracle.com/javase/specs/jls/se7/html/jls-7.html#jls-7.5): "A type in an unnamed package (§7.4.2) has no canonical name, so the requirement for a canonical name in every kind of import declaration implies that (a) types in an unnamed package cannot be imported, and (b) static members of types in an unnamed package cannot be imported. As such, §7.5.1, §7.5.2, §7.5.3, and §7.5.4 all require a compile-time error on any attempt to import a type (or static member thereof) in an unnamed package." However, this seems to have been inconsistent with Section 6.7 (https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.7), which did define the canonical name of types in an unnamed package. In the JLS for SE 8, this sentence was deleted again, and instead the sentence "The name must be qualified (§6.5.5.2), or a compile-time error occurs." was added in Section 7.5.1 (https://docs.oracle.com/javase/specs/jls/se8/html/jls-7.html#jls-7.5.1). But the definition of qualified names in Section 6.5.5.2 seems to cover the present case, so this import statement would have been allowed again. Now, since SE 9, Section 7.5.1 again prohibits imports from an unnamed package (see above).
This may or may not be related to bug 321464.
This bug is not specific to default package. Given this: package foo.bar; import java.util.Iterator; public class Demo implements Iterable<Nested> { public class Nested { } @Override public Iterator<Nested> iterator() { return null; } } The Quickfix on <Nested> to "import 'Nested' (foo.bar.Demo)" is a no-op. Also reported in vscode-java (which consumes JDT via jdt.ls): https://github.com/redhat-developer/vscode-java/issues/2154
