Community
Participate
Working Groups
The JAR located at '.mtj.tmp\emulation' does not cotains any top level not public class. They are compiled, in the 'bin' folder anyway. So, when the MIDlet stars, throw an NoClassDefFoundError exception. This bug was not present at version 0.9, the same project worked perfectly. TRACE: <at java.lang.NoClassDefFoundError: org.foo.NonPublicClassName>, startApp threw an Exception java.lang.NoClassDefFoundError: org.foo.NonPublicClassName - java.lang.Class.invoke_verify(), bci=0 - java.lang.Class.initialize(), bci=117 - gs.infomapa.me.MIDletInfoMapa.startApp(), bci=8 - javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1 - com.sun.midp.midlet.MIDletPeer.startApp(), bci=7 - com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=269 - com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=52 - com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=8 - com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=161 - com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
Hi Guillermo, What version of MTJ are you using ? This issue was fixed for quite a long time now. Please consider updating your MTJ plugins :) Best Regards, David Marques (In reply to comment #0) > The JAR located at '.mtj.tmp\emulation' does not cotains any top level not > public class. They are compiled, in the 'bin' folder anyway. > > So, when the MIDlet stars, throw an NoClassDefFoundError exception. > > This bug was not present at version 0.9, the same project worked perfectly. > > TRACE: <at java.lang.NoClassDefFoundError: org.foo.NonPublicClassName>, > startApp threw an Exception > java.lang.NoClassDefFoundError: org.foo.NonPublicClassName > - java.lang.Class.invoke_verify(), bci=0 > - java.lang.Class.initialize(), bci=117 > - gs.infomapa.me.MIDletInfoMapa.startApp(), bci=8 > - javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1 > - com.sun.midp.midlet.MIDletPeer.startApp(), bci=7 > - com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=269 > - com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=52 > - com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=8 > - com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=161 > - com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26 >
I've downloaded MTJ yesterday (2009-08-27), from Eclipse Galileo update site. The version showed in 'About Eclipse Features' dialog is: ****************************************************** Mobile Tools Java Version: 1.0.0.v200906121354-7V7A7BFEx2XZqZ-lBoXfQ Build id: 200906121354 ****************************************************** (In reply to comment #1) > Hi Guillermo, > > What version of MTJ are you using ? This issue was fixed for quite a long time > now. Please consider updating your MTJ plugins :) > > Best Regards, > > David Marques > > (In reply to comment #0) > > The JAR located at '.mtj.tmp\emulation' does not cotains any top level not > > public class. They are compiled, in the 'bin' folder anyway. > > > > So, when the MIDlet stars, throw an NoClassDefFoundError exception. > > > > This bug was not present at version 0.9, the same project worked perfectly. > > > > TRACE: <at java.lang.NoClassDefFoundError: org.foo.NonPublicClassName>, > > startApp threw an Exception > > java.lang.NoClassDefFoundError: org.foo.NonPublicClassName > > - java.lang.Class.invoke_verify(), bci=0 > > - java.lang.Class.initialize(), bci=117 > > - gs.infomapa.me.MIDletInfoMapa.startApp(), bci=8 > > - javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1 > > - com.sun.midp.midlet.MIDletPeer.startApp(), bci=7 > > - com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=269 > > - com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=52 > > - com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=8 > > - com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=161 > > - com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26 > > >
I did notice that bug as well (or at least a similar one) - it seems that is sometimes happens when creating a new class that this new class is not checked when checking the class-path in the application descriptor. The result is that the code looks fine in eclipse but the class won't appear in the created jar. This happened to me with version 1.0 but I haven't tried it on the current RC1.
I was able to track this bug to the Package Builder and the build.properties file. So far I know, Package Builder is the last builder to run and filters all classes in bin folder that no math any of the build.properties file entries. Here is the problem, build.properties editor, only lets you select files from your project, but I’ve an “abstract” project with common classes that my MIDlet project references and I cannot include its bin folder in with the build.properties editor. The result: all classes of this referenced project are getting filtered. I should disable de Package Builder, and my project will run OK again. I haven’t tried yet. Anyway, I think this is a fiximprove for the build.properties editor.
If the dependent projects are chosen to be exported from the build path properties they will be included on the package build. You can achieve this by right clicking you project selecting Properties->Java Build Properties->Order & Export and checking the dependent projects. I will keep this report as an enhancement request for controlling the included parts of dependent projects through build.properties.
A fix for the original problem is relased for bug 332529 closing this as a duplicate
closing as duplicate *** This bug has been marked as a duplicate of bug 332529 ***
