JDK-4073162 : rmic generates a compiler error -- sun.tools.java.CompilerError
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1997-08-20
  • Updated: 1997-08-27
  • Resolved: 1997-08-27
Related Reports
Duplicate :  
JDK-4073373 - rmic may throw CompilerError when looking for classes with spaces in their name
Description
javWhile running rmic on RMI Naming List testsusing the latest JDK1.2 build,  got the
following message:-

error: An error has occurred in the compiler; please file a bug report (http://java.sun.com/cgi-bin/bugreport.cgi).
1 error
----------log:rmic(7/491)----------
sun.tools.java.CompilerError: mangle NItem1Impl     javasoft$sqe$tests$api$java$rmi$Naming$NItem2Impl     javasoft$sqe$tests$api$java$rmi$Naming$NItem3Impl     javasoft$sqe$tests$api$java$rmi$Naming$NItem4Impl
	at sun.tools.java.Type.mangleInnerType(Type.java)
	at sun.tools.java.Type.tClass(Type.java)
	at sun.tools.java.ClassDeclaration.<init>(ClassDeclaration.java)
	at sun.rmi.rmic.Main.doCompile(Main.java)
	at sun.rmi.rmic.Main.compile(Main.java)
	at sun.rmi.rmic.Main.main(Main.java)



The command used:  /js/files/JDK1.2/build/solaris/bin/rmic -d /js/files/adele/JDK1.2/nightly/classes javasoft.sqe.tests.api.java.rmi.Naming.NItem1Impl     javasoft.sqe.tests.api.java.rmi.Naming.NItem2Impl     javasoft.sqe.tests.api.java.rmi.Naming.NItem3Impl     javasoft.sqe.tests.api.java.rmi.Naming.NItem4Impl 

I can provide the source files if needed. BTW, this worked in the JDK1.2I build.
Comments
EVALUATION peter.jones@East 1997-08-20 I haven't been able to reproduce this as described (invoking the rmic command from the command line) yet. I talked to Vella and he couldn't either, so so far it appears to be another problem that only occurs when a Java VM is exec'd by the Harness. Vella is working on getting a better reproducible test case. peter.jones@East 1997-08-20 Here's the latest... Vella reproduced the problem, or at least something very similar to the problem (a CompilerError from "mangleInnerType"), by writing a test Java program that "exec"s the rmic command, to simulate what the test harness does. As it turns out, the CompilerError is caused by passing all of the arguments to rmic as "one argument", so to speak, which can be simulated by putting them in quotes on the command line. If you do not include spaces at either end, inside the quotation, however, rmic will complain that it cannot find the class with the name of that entire quotation, which makes sense. If there is a space at either end, the CompilerError will be produced; presumably, this is the behavior the harness is running into. If all the arguments to rmic are correctly passed as individual arguments, then there is no problem; the rmic works fine. In fact, the same behavior can be experienced without Vella's exec test; you just need to simulate the same argument weirdness on the command line. The following output demonstrates the different possibilities: [terrier]<peter> 69 % !41 setenv CLASSPATH /js/files/adele/JDK1.2/nightly/classes [terrier]<peter> 70 % !42 /js/files/JDK1.2/build/solaris/bin/rmic "-d /tmp/classes javasoft.sqe.tests.api.java.rmi.Naming.NItem1Impl" rmic: invalid flag: -d /tmp/classes javasoft.sqe.tests.api.java.rmi.Naming.NItem1Impl use: rmic [-g][-O][-debug][-depend][-nowarn][-verbose][-classpath path][-nowrite][-d dir][-dstub dir][-dskel dir][-show][-keepgenerated] classname... {This makes sense because rmic gets the whole quoted string as an argument; it starts with a '-', so it must be an option; but that whole thing isn't a legal option!} [terrier]<peter> 71 % !43 /js/files/JDK1.2/build/solaris/bin/rmic " -d /tmp/classes javasoft.sqe.tests.api.java.rmi.Naming.NItem1Impl" error: Class -d /tmp/classes javasoft.sqe.tests.api.java.rmi.Naming.NItem1Impl not found. 1 error {Again, this makes sense because rmic gets the whole quoted string as its one and only argument; it doesn't start with a '-', so it must be a class name. But there is no such class found, of course.} [terrier]<peter> 72 % !44 /js/files/JDK1.2/build/solaris/bin/rmic " -d /tmp/classes javasoft.sqe.tests.api.java.rmi.Naming.NItem1Impl " sun.tools.java.CompilerError: mangle NItem1Impl at sun.tools.java.Type.mangleInnerType(Type.java) at sun.tools.java.Package.getBinaryFile(Package.java) at sun.tools.javac.BatchEnvironment.loadDefinition(BatchEnvironment.java) at sun.tools.java.ClassDeclaration.getClassDefinition(ClassDeclaration.java) at sun.rmi.rmic.Main.doCompile(Main.java) at sun.rmi.rmic.Main.compile(Main.java) at sun.rmi.rmic.Main.main(Main.java) error: An error has occurred in the compiler; please file a bug report (http://java.sun.com/cgi-bin/bugreport.cgi). 1 error [terrier]<peter> 73 % {This is the confusing case... and it is presumably what the harness is doing.} Actually... *all* of the preceding cases simply work fine with a build as not-so-long-ago as JDK1.2I. Preliminary tests show that the way args get passed to main hasn't really changed (see ~jones/java/test/PrintArgs.java). But this CompilerError that happen in Type.mangleInnerType does exactly occur if there are extraneous spaces in the class name. The ". " combination is used internally by the compiler to represent fully qualified inner class identifiers. The Identifier.isInner() returns true if an Identifier contains a space (thus it must be unmangled...). mangleInnerType() first converts all ". " into "$", and then it throws the CompilerError the resulting identifier isInner(), which will occur if extraneous spaces remain. More shortly... peter.jones@East 1997-08-20 Ha! OK, now I see what is going on here... this is a weird bug. Up until very recently (including the JDK1.2I build, and EA2), the scripts that handled the execution of tools like "rmic", "javap", etc. would (by accident?) expand a single argument with spaces into multiple arguments as delimited by the spaces. For example, rmic "a b" was equivalent to rmic a b and apparently, the test harness was taking advantage of this. This behavior was filed as bugid 4053337, and it was "fixed" on 8/1, and through the most recent code check-in, it made its way around to our local workspace yesterday. So, the harness in invoking rmic with arguments all strung together in one argument, and in the first case, since that argument starts with a "-", it is considered an option, and it is flagged as an illegal option. In the second and third cases, since it doesn't start with a "-", it is interpreted as a class name, and it can't find the class name, so it fails. What is more ~interesting~ is the cases in which the compiler error occurs. Trying to look for the file, mangleInnerType needs to get called because class files are stored with mangled names. There are no inner types involved here. But as mentioned above, mangleInnerType throws the CompilerError if, when it's done doing ". "->"$" replacement on the class name with the package qualifier stripped off, isInner() still returns true. This happens if the "indexOf" a ' ' in the identifier name is > (NOT >=) 0, so in other words, the CompilerError will get thrown if the Identifier contains any spaces, UNLESS the first character is a space. Therefore, the following cases do not throw CompilerErrors: rmic " -d /tmp/classes a.b" rmic " -d /tmp/classes a" rmic " -d /tmp/classes a " rmic " a.b c.d e.f" and the following cases do: rmic "a b" rmic "a " rmic " -d /tmp/classes a.b " Now, what to do... I'm inclined to think that the bug fix for 4053337 was correct; the tools should be consistent, and if you do need to use arguments with spaces, it should be supported (if you want to supply a directory name with a space in it to the "-d" option, for example). The "real" problem is that the CompilerError can get thrown; the failure shouldn't be this ungraceful. It could be fixed in rmic, but I'm inclined to request that it get fixed in the compiler instead. "javap", for example, has exactly the same behavior now; try doing javap "a b". But what about the harness? It should be fixed to not pass arguments to rmic that way. The question is is that practical for our QA team right now? I'll leave this bug open until this is resolved. And I'll file a compiler bug about this problem. peter.jones@East 1997-08-26 I think that Vella is OK with changing the relevant harness code that starts up "rmic" to do the right thing, so I'm going to close this bug (and mark it as a duplicate of the compiler/tools bug I filed about the CompilerError).
11-06-2004