Re: [Eclipseme-users] ClassNotFound problem with Eclipse 3.3 and EclipseME 1.7.9 [SOLVED]

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

PAR...@OR... wrote:
> Berk, final methods are allowed in MIDP. In fact, it's one of the tricks you can use to save a few bytes in the final obfuscated JAR file. I can't say I understand why removing the final method fixed the problems you were seeing, but try adding another final method and see if it works now.
>   
You are absolutely right, it turns out it is the "finalize" method that 
is not allowed. I had it declared the method as "final finalized," and I 
guess I didn't read the error message properly. Initially I was hoping 
to put some code in there that would right my data structure to the RMS 
when my model class was destroyed. It got fixed when I removed the class 
altogether. Thanks for pointing that out!


> Parag Chandra
> Senior Software Developer
> par...@or...
> 404-439-5821
> -----Original Message-----
> From: Berk Birand [mailto:ber...@su...] 
> Sent: Tuesday, June 24, 2008 6:46 AM
> To: ecl...@li...
> Subject: Re: [Eclipseme-users] ClassNotFound problem with Eclipse 3.3 and EclipseME 1.7.9 [SOLVED]
>
> Hi all,
>
> I finally figured out why things weren't working as expected. The debug 
> mode of EclipseME helped me a lot. It turns out my first mistake was in 
> deleting the content of the .eclipseme.tmp directory, including the 
> emulator/ and verified/ directories. I thought those would be 
> regenerated the next round, but I suppose that wasn't the case, since I 
> kept seeing FileNotFound exceptions in the EclipseME console.
>
> After that was done, the content of the folders were created as 
> expected, but I still got the ClassNotFound exception. Looking at the 
> preverifier output, I realized that was because I had a method declared 
> as "final," which apparently is not allowed in MIDP. Once I took that 
> out, the classes were preverified, and the emulator ran normally.
>
> I apologize for making a novice mistake like this, but I am indeed a 
> beginner and have been developing for this platform for about 3 days. On 
> the flip side, I learned a lot about writing programs for this platform, 
> and I hopefully won't be wasting your time with inconsequential problems 
> (I'll be wasting it with more difficult ones).
>
> Thanks to everyone who have answered,
> Sincerely,
>   Berk
>
> Berk Birand wrote:
>   
>> First of all, thanks a lot for all your quick answers. This has been 
>> really bugging me, and it is somewhat nice to hear that the solution 
>> doesn't stem from me having something configured improperly.
>>
>> After learning about the .eclipseme.tmp directory, I made some more 
>> observations that might be of help. I removed the content of the /bin 
>> directory, and the .eclipseme.tmp directories, as explained in 
>> http://eclipseme.org/docs/buildingRef.html . I then opened Eclipse, and 
>> attempted to re-build the project, getting the same ClassPathNotFound 
>> exception. However when I then check in those directories, I don't see 
>> any new .class files, so nothing appears to have been compiled. There is 
>> a .jar file in the /emulation subfolder, but it only contains a 
>> MANIFEST.MF file.
>>
>> In short, the reason why it cannot find the class is because the sources 
>> are never compiled, not because they are unreachable.
>>
>> Does anybody know why EclipseME would refuse to compile the project? How 
>>   can I force it to do that? Or is there any way to diagnose why it is 
>> not doing so?
>>
>>
>> I enabled the EclipseME debug mode by using the command-line switch, but 
>> the EclipseME error console only displays this:
>>
>>  > PreverificationBuilder.getRuntimeJar project = P/GroceryList
>> < PreverificationBuilder.getRuntimeJar project = P/GroceryList
>>
>> Thank you in advance,
>>   Berk
>>
>>
>> Heiko Selber wrote:
>>     
>>> BTW: Putting /bin into the classpath shouldn't help anyway, because MIDlets must be preverified. So, if anyting, you should add /verified, not /bin.
>>>
>>> As to the original problem: For some reason, over the air doesn't always work for me (perhaps because of missing write permissions).
>>>
>>> But when I do J2ME -> Create Package and specify the MIDlet explicitly in the launch configuration, I can run it in the emulator. But then you always have to create the package explicitly after modifying the sources.
>>>
>>> Heiko
>>>       
>>     
>>> -------- Original-Nachricht --------
>>>       
>>>> Datum: Tue, 24 Jun 2008 00:39:24 +0200
>>>> Von: Markus Sinner <si...@ps...>
>>>> An: ecl...@li...
>>>> Betreff: Re: [Eclipseme-users] ClassNotFound problem with Eclipse 3.3 and EclipseME 1.7.9
>>>> You should open a bug report on sourceforge if it persists...
>>>>
>>>> Did you run your midlet "over the air"? Try specifying the midlet in the
>>>> run-tab, if I remember right it is the third option.
>>>>
>>>>
>>>> Berk Birand schrieb:
>>>>         
>>>>> Hi all,
>>>>>
>>>>> I am developing my first MIDlet using Eclipse 3.3 and EclipseME 1.7.9. 
>>>>> The development started fairly smoothly, and I managed to run the 
>>>>> important demos in the Sun WTK 2.5.2, I recently ran into some weird 
>>>>> problems that no amount of Googling could solve. It all began when I 
>>>>> made a lot of changes to the source code of my own application, and 
>>>>> wanted to see how it worked in the emulator. When I ran the project, 
>>>>> none of the changes showed up, and I would still see some sysout prints 
>>>>> that I had removed long ago. I then went into the Eclipse workspace, and
>>>>> removed the content of the /bin directory, thinking that it would 
>>>>> recompile everything from the source.
>>>>>
>>>>> Instead, I started running into these errors:
>>>>>
>>>>> Running with storage root 
>>>>> /home/graffiti/j2mewtk/2.5.2/appdb/DefaultColorPhone
>>>>> Running with locale: en_US.UTF-8
>>>>> Running in the untrusted security domain
>>>>> java.lang.ClassNotFoundException: org/berk/GroceryList
>>>>>     at com.sun.midp.midlet.MIDletState.createMIDlet(+29)
>>>>>     at com.sun.midp.midlet.Scheduler.schedule(+52)
>>>>>     at com.sun.midp.main.Main.runLocalClass(+28)
>>>>>     at com.sun.midp.main.Main.main(+80)
>>>>> Execution completed.
>>>>> 2755738 bytecodes executed
>>>>> 40 thread switches
>>>>> 1665 classes in the system (including system classes)
>>>>> 14243 dynamic objects allocated (437872 bytes)
>>>>> 1 garbage collections (0 bytes collected)
>>>>>
>>>>> Somebody else had a similar problem, and they proposed including the 
>>>>> /bin directory as an "Extra Emulator Parameter" using the -cp switch. 
>>>>> When I do, the emulator does manage to find the class, but I get the 
>>>>> following error instead:
>>>>>
>>>>>
>>>>> Running with storage root 
>>>>> /home/graffiti/j2mewtk/2.5.2/appdb/DefaultColorPhone
>>>>> Running with locale: en_US.UTF-8
>>>>> Running in the untrusted security domain
>>>>> Error verifying method org/berk/GroceryList startApp()V
>>>>> [...]
>>>>> ALERT: java/lang/VerifyError: org/berk/GroceryList.
>>>>> Execution completed.
>>>>> 2750987 bytecodes executed
>>>>> 32 thread switches
>>>>> 1666 classes in the system (including system classes)
>>>>> 14313 dynamic objects allocated (438588 bytes)
>>>>> 2 garbage collections (378116 bytes collected).
>>>>>           
>
>   
>
>
>   
>>>>> I really do not know what else I can try, or what other diagnostic 
>>>>> information I can send you that could be of help. I heard the log mode 
>>>>> of EclipseME could be useful, but I couldn't find a way of enabling it.
>>>>>
>>>>> If you have any leads, please let me know,
>>>>>
>>>>> Sincerely,
>>>>>  Berk
>>>>>
>>>>>
>>>>>           
>>>> -------------------------------------------------------------------------
>>>>         
>>>>> Check out the new SourceForge.net Marketplace.
>>>>> It's the best place to buy or sell services for
>>>>> just about anything Open Source.
>>>>> http://sourceforge.net/services/buy/index.php
>>>>> _______________________________________________
>>>>> Eclipseme-users mailing list
>>>>> Ecl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>>>>>   
>>>>>           
>>>> -------------------------------------------------------------------------
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>> http://sourceforge.net/services/buy/index.php
>>>> _______________________________________________
>>>> Eclipseme-users mailing list
>>>> Ecl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>>>>         
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Eclipseme-users mailing list
>> Ecl...@li...
>> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>>
>>
>>     
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Eclipseme-users mailing list
> Ecl...@li...
> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Eclipseme-users mailing list
> Ecl...@li...
> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>
>
>