JDK-4466791 : Public class NoPackBean no longer available in JDK1.4
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.4.0
  • Priority: P1
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-06-06
  • Updated: 2001-06-15
  • Resolved: 2001-06-13
Related Reports
Duplicate :  
Relates :  
Description
I start API tests for JavaHelp under JCK/JavaTest. All tests have passed under JDK1.3.X but under JDK1.4.0-build66 two tests failed.

The failed tests are importing NoPackBean. Result of the JavaTest is:
api/javax_help/HelpUtilities/test.html#GetHelpSetNameFromBean                           Error. Compilation failed unexpectedly [exit code 1]
api/javax_help/HelpUtilities/test.html#GetIDStringFromBean                              Error. Compilation failed unexpectedly [exit code 1]

Attached is the *.java classes and *.jtr files. Problem is, that the NoPackBean.class and NoPackBeanBeanInfo.class are exist in the correct place.

Comments
EVALUATION This bug report is in-complete. Please provide paths to NoPackBean class files. Could you also include paths to your testsuite. These are not under 1.3.1 or 1.4 JDK/SDK. Both java files fails to compile because I do not have the CLASSPATH with correct classes. import NoPackBean; I think this will no longer work in JDK 1.4 Need bigger path or just use one in local dir that you get for free. Make sure . in your path. ###@###.### 2001-06-13 The criticall tests you can see in this location: jdk.eng:/java/javahelp/ws/wsjhelp ... a TeamWare worspace ... wsjhelp/src/javahelp/tests/api/javax_help/HelpUtilities In both tests is 'import NoPackBean;' and those tests faliled onlu for JDK1.4 for 1.3.1 work correctly. A *.class files for NoPackBean are on the correct place and all test process is automated. There is only difference between size of class NoPackBeanBeanInfo: -- JDK1.3.0_02 and JDK1.3.1 -- size == 986B -- JDK1.4.0 -- size == 927B But I'm not sure if it is the problem. Differences between 1.3.1 and 1.4 JDK The compiler now rejects import statements that import a type from the unnamed namespace. Previous versions of the compiler would accept such import declarations, even though they were arguably not allowed by the language (because the type name appearing in the import clause is not in scope). The specification is being clarified to state clearly that you cannot have a simple name in an import statement, nor can you import from the unnamed namespace. To summarize, the syntax import SimpleName; is no longer legal. Nor is the syntax import ClassInUnnamedNamespace.Nested; which would import a nested class from the unnamed namespace. To fix such problems in your code, move all of the classes from the unnamed namespace into a named namespace. Please fix import statements in testcases specified. gary.collins@East 2001-06-13 ###@###.### 2001-06-15 Please could you point me to correct document and paragraph in JLS which are describing that ??? We try to find correct paragraph about that, but we cannot find that. Some comments: -------------------%<---------------------- %<---------------- Just to be sure, I've downloaded JLS-2nd edition and here's the result (numbers refer to JLS spec paragraphs): 6.7: The fully qualified name of a top level class or top level interface that is declared in an unnamed package is the simple name of the class or interface. --- fully qualified name for NoPackBean is "NoPackBean" For every package, top level class, top level interface and primitive type, the canonical name is the same as the fully qualified name. --- the canonical name for NoPackBean is "NoPackBean" 7.3: Which compilation units are observable is determined by the host system. --- I assume that this statement refers to unreadable files and such exceptional cases + other unspecified Java SDK impl & OS behaviour. 6.6: If a class or interface type is declared public, then it may be accessed by any code, provided that the compilation unit (��7.3) in which it is declared is observable. --- I assume that "any code" includes an import statement, too. 7.5.1: A single-type-import declaration imports a single type by giving its canonical name (6.7) - it must be accessible (6.6) 7.4.2: An implementation of the Java platform must support at least one unnamed package; [...] only one unnamed package is observable at a time, namely the one that is associated with the "current working directory." The precise meaning of "current working directory" depends on the host system. ---- From the above, I inferred that the import statement was used with a valid canonical type name for a public type. The only reason why it could be rejected is, that the type is not observable (which implies that it is not accesible). I need a clarification which statement of the JLS covers this situation: is javac a part of "host system" and does it leave the location of unnamed package undefined, so units in there are not observable (unless included explicitly in the compilation) ? I am allowed to refer from one class in an unnamed package to another one (both sources are in the working directory), even if that other unit is not explicitly specify on commandline. Does the definition of unnamed package observability differ from the previous case ? Is there any other condition I've overlooked that may qualify the compiler to reject the statement ? ----------------------%<-----------------------------%<--------------------- Please see docs at : http://java.sun.com/j2se/1.4/compatibility.html#incompatibilities1.4 Regards, Gary Collins gary.collins@East 2001-06-15
15-06-2001