>>>> "Andrew" == Andrew Overholt
<overholt(a)redhat.com> writes:
Andrew> I came across a weird issue while trying to build rssowl.
Andrew> I've attached the test file. Trying this works:
Andrew> ecj RSSOwlI18nZHtw.java
Andrew> while this appears to hang:
Andrew> ecj -encoding utf8 RSSOwlI18nZHtw.java
I can't even run ecj on my FC4 box :-(
I'm using eclipse-ecj-3.1.0_fc-0.RC3.3. When I try 'ecj
RSSOwlI18nZHtw.java', I see:
Exception in thread "main" java.lang.NoClassDefFoundError: while resolving
class: org.eclipse.jdt.internal.compiler.batch.Main
at java.lang.VMClassLoader.transformException(java.lang.Class, java.lang.Throwable)
(/usr/lib/libgcj.so.6.0.0)
at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0)
at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
at org.eclipse.jdt.internal.compiler.batch.Main.main(java.lang.String[])
(/usr/lib/eclipse/plugins/org.eclipse.jdt.core_3.1.0.jar.so)
at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.problem.ProblemSeverities not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(/usr/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
...5 more
Andrew> To add to the bizarre-ness, this appears to be as small as I can make
Andrew> the test file without it being unable to reproduce the problem; I can't
Andrew> seem to remove any of the lines if I want to continue to reproduce. In
Andrew> another interesting twist, renaming the file (and class) to
"TestUTF8"
Andrew> does not reproduce the problem.
Andrew> Anyone know what's going on?
This would be consistent with some kind of buffer boundary issue --
like if some obscure charset translation failure occurs only when the
triggering data appears at the boundary of an internal buffer. With a
bug like this, small changes to the text would hide the failure.
That's just one possible theory though.
Tom