United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4073162 : rmic generates a compiler error -- sun.tools.java.CompilerError

Submit Date:
Updated Date:
Project Name:
Resolved Date:
Affected Versions:
Fixed Versions:

Related Reports

Sub Tasks

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
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.



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).

Hardware and Software, Engineered to Work Together