Please provide more details. I cannot reproduce it. 

I use NB + mobility pack
steps:
1, run IDE with userdir user1, create project P1, add new
emulator(platform) to it
2, run ide with new userdir and open the P1 project (there are
unresolved  reference problems)
3,open a file from P1 project
-exception in console appears

-it's enought to open file from project with unresolved reference
problems ;)

Tom, could the FatalError be transformed into an exception we could
catch? I think it is not a good idea to catch Error or Throwable. This
problem is nothing fatal, IMO we could just ignore it. The result is
that the error annotations will not be displayed if java.lang is
missing on a classpath. Or do you think it should be handled in a
different way?

Sure, I can catch the exception, change it, hide it, or wrap it up as
a present for you, but what is right?  I think turning it off is
wrong, as not having a path to java.lang suggests that the build
environment is very, very broken.  How can the project be built?  If
it can, then the real problem is that the correct classpath is not
being passed to the error checker.

gjast now throws a CompilerException wrapper for javac internal
exceptions and errors, which the error checker logs.  This eliminates
the scary message from the user's perspective, without hiding any
problems.

happend to me again with build 0501041900, FatalError printed to
console when opening java file from just opened project

Could you please attach the new stacktrace?

Created attachment 19485 [details]
part of messages.log

old target milestone, please re-evaluate

*** Issue 53440 has been marked as a duplicate of this issue. ***

I would consider this bug P2, since at least for me it completely
prevents me from using basic features like Find Usages. What triggers it?

That's strange, because the exception comes from the ASErrorChecker,
which is only used to get syntactic and semantic errors for the file
when updating error annotations, so it should not have any impact on
"find usages" functionality. So, I doubt it has anything to do with
the broken "find usages". Maybe this exception may give us a hint that
something is wrong - in this particular case it seems that JDK was not
found on the classpath returned for a given file.

Tom, it seems that the FatalError still does not get wrapped by
CompilerException. Could you please check it?

Jesse, this does not seem to be the cause of your problems with find
usages, since this only means that errors underlining for some file
failed. This happened because the ClassPath.BOOT seems to not contain
the JDK (java.lang.* package).
I am changing this to P3, I will reopen your original issue, set its
priority to P2 and change the summary.

Lucas, please attach your system's copy of gjast.jar and reassign this
bug to me.  

Although your stack trace suggests that you have the latest code, the
FatalError appears to be ignored by a surrounding "try/catch
Throwable" block in ASErrorChecker.parse():

...
	try {
            in = request.getReader();
	    compile(filename, in);
	    return log.nerrors;
	} catch (Throwable t) {
	    throw new CompilerException(t);
	} finally {
...

  I decompiled my version of ASErrorChecker and the try/catch is
compiled correctly in my version.  Since FatalError is a subclass of
Error which subclasses Throwable, this missed catch may be due to a
JVM bug.

The exception seems to be caught and printed out in
ASErrorChecker.compile().

Tom?

Removed thread dump statement from code.

v

Reorganization of java component