Michael Koch wrote: > On Sun, Mar 02, 2008 at 12:01:03PM +0000, Andrew Haley wrote: >> Michael Koch wrote: >>> On Sun, Mar 02, 2008 at 10:35:28AM +0000, Andrew Haley wrote: >>>> And what was the reason? I need to know. >>> !ENTRY org.eclipse.osgi 4 0 2008-03-02 12:38:50.196 >>> !MESSAGE Application error >>> !STACK 1 >>> java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin >>> at >>> org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402) >>> at >>> org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) >>> make: *** [build-stamp] Fehler 13 >>> >>> The only small strange thing is that org.eclipse.core.runtime.Plugin and >>> org.eclipse.core.runtime.Platform are in the same Jar. This must be some >>> OSGi issue. At least I know now where to start debugging. >> Oh, right, so you *don't* actually know what the cause of this is. Me >> either, but >> I'm debugging it at the moment. > > Yeah, yesterday I thought it was just a missing jar file. Today I took a > closer look at at it... > >> gcj should not distinguish between natively compiled code and bytecode. >> The fact that it makes a difference must be a bug. > > Sounds like it. Can I somehow help?
I don't think so. My plan is to add a lot of class loader tracing code to libgcj, and I will then trap at the point where compiled succeeds but interpreted doesn't. There are areas where compliant jvms might behave differently. For example, the exact time when dependent classes are loaded isn't defined. Maybe at class initialization time, maybe later. All the the spec requires is that ClassNotFoundExceptions aren't raised until classes are referred to. So, it is possible that Eclipse requires some precise semantics of class loading beyond what is strictly required by the spec. Maybe compiled code loads classes earlier than interpreted code, and maybe *the effective classpath has changed* by the time gij tries to load org.eclipse.core.runtime.Plugin. Andrew. _______________________________________________ pkg-java-maintainers mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
