error: cannot find file for class xyz

[Andrew Haley <aph at redhat dot com>]

Brian Sullivan writes:
 > Hello,
 > 
 > I'm trying to compile something from bytecode (a .jar file) at the 
 > moment, using the latest gcj for mingw at the thisiscool site.  This is 
 > a jar output by our Cobol compiler for Java.
 > 
 > I'm getting warnings about unreachable bytecodes.  I understand warnings 
 > about unreachable real source, but unreachable bytecode is not something 
 > a gcj user should be concerned with.  But those are only warnings.

I don't think we should silence this warning by default, as it is
indicative of a real bug in a bytecode generator.  Perhaps we should
allow it to be disabled.

 > The errors I get involve the fact that a class is not present:
 > [DashoPro-V1.2-120198]:0: error: cannot find file for class 
 > com.legacyj.jfc.LMenu
 > 
 > and errors derived from the missing class, such as:
 > [DashoPro-V1.2-120198]:0: error: class 'com.legacyj.jfc.LMenu' has no 
 > method named 'getJPopupMenu' matching signature '()Ljavax/swing/JPopupMenu;'
 > 
 > I know the class is not present; it shouldn't be.  The runtime
 > behavior is to throw an exception when attempting to access it,
 > recover, and go on about our merry business; the .jar being
 > compiled does execute properly using any Sun or IBM Java (yes, even
 > jview) on Windows, Linux, etc.  Is there a way to tell it that I
 > want any unknown classes to be attempted as interpretation, failing
 > that to throw exceptions at runtime?

We have been working on a way to allow compiled code to call
interpreted code, but it is still not perfect.

Quoth Tromey:

"Right now, having precompiled code refer to interpreted code is
unsupported.  So if you want to compile your application, you'll have
to compile the libraries to which it directly refers.

"On the trunk there are some patches to make the `-fno-assume-compiled'
feature work better.  This feature gives better support for this sort
of thing.  However, I think there are still some bugs in this code.
It is something I think we'll probably support in the 3.4 release (or
3.5, or ... -- depending on how much work goes into it)."

For now, your best bet is to change your code to use reflection to
load the missing classes.

You can always create dummy classes that throw execptions, but I guess
you already figured that out.

Andrew.