JDK-4073373 : rmic may throw CompilerError when looking for classes with spaces in their name
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.1.2,1.1.3,1.1.8,1.2.0,1.2.2
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS:
    generic,solaris_2.5,windows_95,windows_nt generic,solaris_2.5,windows_95,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 1997-08-21
  • Updated: 2017-07-19
  • Resolved: 2017-07-19
Related Reports
Duplicate :  
JDK-4066450 - rmic: error: An error has occurred in the compiler;
Duplicate :  
JDK-4073162 - rmic generates a compiler error -- sun.tools.java.CompilerError
Duplicate :  
JDK-4067900 - When I use "rmic -show", it displays a compiler error.
Description
This isn't strictly a "javac" issue, but it is caused by compiler tools code
used by the tools with which the bug is an issue, so I figured I would put it
in the compiler category for now.

The problem is that if you use rmic or javap with a class name that, with
anything that might qualify as a package qualifier stripped off, contains
spaces in other than the first position, a CompilerError is thrown.  For
example:

[terrier]<peter> 41 % javap "a b"
sun.tools.java.CompilerError: mangle a b
        at sun.tools.java.Type.mangleInnerType(Type.java)
        at sun.tools.java.Type.tClass(Type.java)
        at sun.tools.util.LoadEnvironment.classExists(LoadEnvironment.java)
        at sun.tools.javap.JavaP.displayResults(JavaP.java)
        at sun.tools.javap.JavaP.perform(JavaP.java)
        at sun.tools.javap.JavaP.main(JavaP.java)

This only happens with the most recent (8/20) putback of changes to the
JDK 1.2 beta workspace (it did not occur with JDK 1.2I, at least as long as
you use the command line wrapper).  It was caused by the fix to 4053337,
where the wrapper scripts for these tools no longer convert single arguments
with spaces into separate arguments to the tool (which was happening
accidentally).

The cause of this bug is that Type.mangleInnerType is called because when
looking for the binary class file, the mangled representation of inner class
names must be used in file names.  This strips off package qualifiers,
replaces ". " with "$", but then if Identifier.isInner() return true, a
CompilerError will get thrown.  But Identifier.isInner() will return true
if indexOf(' ') > 0, so if there are any extraneous spaces in the identifier
after the first position, it will still return true.
Comments
rmic should not be using the old compiler api anyway.
19-07-2017
EVALUATION The problem here is that the tools are accepting command-line input and passing it into compiler internals without validating the syntactic well-formedness constraints that are normally assured by the compiler's parser. It does not make sense to weigh down the normal name-resolution path within the compiler with "syntax checks" that duplicate what the parser has already done. It is thus the responsibility of the tools to validate the input they receive in an analogous manner. To make this easier, I would happily entertain a suggestion to add a method to the compiler that would perform the necessary validation if this would help in fixing the tools. It is not necessary that this check be quite as thorough as the parser, but permitting embedded spaces is definitely a no-no. william.maddox@Eng 1997-10-22 javap is being rewritten for other reasons, so I'm reassigning this to rmic. ###@###.### 2002-06-06 Note that this bug is no longer present in the new (but not yet default) implementation of rmic that was added for 4911536 (although it remains in the default oldjavac-based implementation). This bug will be considered fixed when the new implementation becomes the default (in some future release). ###@###.### 2003-10-28 Committing to Mustang on the assumption that 4819896 is fixed by making the new implementation of rmic the default and only implementation. ###@###.### 2004-11-29 23:00:37 GMT Decommitting for Mustang because of the dependency on 4819896. ###@###.### 2005-06-21 21:40:29 GMT
29-11-2004
WORK AROUND Since this only occurs for failures anyway, a workaround isn't really necessary.
11-06-2004
SUGGESTED FIX Somewhere along the path of getClassDefinition, reject such bogus class names more gracefully than throwing a CompilerError. --- The suggested fix is not appropriate. The internal name-resolution mechanisms of the compiler quite rightfully rely on the fact that the parser has already rejected ill-formed class names. The problem here is that the tools call these routines without verifying the syntactic validity of their arguments. william.maddox@Eng 1997-10-22
22-10-1997