-
Bug
-
Resolution: Unresolved
-
P4
-
None
-
1.4.1
-
Fix Understood
-
generic
-
generic
The spec for Class.forName(), Class.getName() and any other methods which return
or require a String representation nested-class names with '$' needs to be
updated to reflect the current behaviour. Specifically, rather than state that
we return/require the "fully qualified name", we should state that we expect
the "binary name" as defined in the JVM Spec 2nd ed, section 13.1. A brief
description of what this means should be included.
Background and the justification for this clarification may be found in 4378381.
-- iag@sfbay 2002-01-24
or require a String representation nested-class names with '$' needs to be
updated to reflect the current behaviour. Specifically, rather than state that
we return/require the "fully qualified name", we should state that we expect
the "binary name" as defined in the JVM Spec 2nd ed, section 13.1. A brief
description of what this means should be included.
Background and the justification for this clarification may be found in 4378381.
-- iag@sfbay 2002-01-24
- relates to
-
JDK-8310814 Clarify the targetName parameter of Lookup::findClass
- Resolved
-
JDK-8310815 Clarify the name of the main class, services and provider classes in module descriptor
- Resolved
-
JDK-4378381 Class.forName() problem with a nested class name
- Closed
-
JDK-8310242 Clarify the name parameter to Class::forName
- Resolved
-
JDK-8314449 Clarify the name of the declaring class of StackTraceElement
- Resolved