Discussion:
ClassNotFound problem with Eclipse 3.3 and EclipseME 1.7.9
Berk Birand
2008-06-23 20:58:37 UTC
Permalink
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
Markus Sinner
2008-06-23 22:39:24 UTC
Permalink
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
> Eclipseme-***@lists.sourceforge.net
> 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
Heiko Selber
2008-06-24 09:33:36 UTC
Permalink
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 <***@psitronic.de>
> An: eclipseme-***@lists.sourceforge.net
> 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
> > Eclipseme-***@lists.sourceforge.net
> > 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
> Eclipseme-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/eclipseme-users

--
----
I condem'n the abuse of apostrophe's.


Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

-------------------------------------------------------------------------
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
Berk Birand
2008-06-24 16:00:31 UTC
Permalink
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 <***@psitronic.de>
>> An: eclipseme-***@lists.sourceforge.net
>> 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
>>> Eclipseme-***@lists.sourceforge.net
>>> 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
>> Eclipseme-***@lists.sourceforge.net
>> 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
Berk Birand
2008-06-24 10:45:34 UTC
Permalink
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 <***@psitronic.de>
>>> An: eclipseme-***@lists.sourceforge.net
>>> 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
>>>> Eclipseme-***@lists.sourceforge.net
>>>> 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
>>> Eclipseme-***@lists.sourceforge.net
>>> 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
> Eclipseme-***@lists.sourceforge.net
> 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
Markus Sinner
2008-06-25 06:01:08 UTC
Permalink
> 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.
That kind of problems always occur in eclipse if you delete folders NOT
using eclipse. If you go to resource view, update it (F5) and then try
again, it should work, because then eclipse "knows" about the current
filesystem. If not, I suggest opening a bugreport.

Thats very annoying about eclipse.

> 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).
I think all of us had similar problems :-)


--

*********************************
***@psitronic.de
http://www.psitronic.de

psitronic IT-Solutions
Markus Sinner
W-Rathenau-Str. 14 - 68642 Bürstadt
Tel.: (+49)6206 / 963513
Fax: (+49)6206 / 963514

-------------------------------------------------------------------------
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
P***@ORACLE.COM
2008-06-25 14:25:22 UTC
Permalink
I wonder if enabling this option:

Window...Preferences...General...Workspace...Refresh automatically

would let EclipseME know that the directory had been deleted? Until I discovered this option last week, my biggest complaint about Eclipse vs. Visual Studio was that the entire Package Explorer had to be manually refreshed any time you made changes outside of Eclipse. I feel like this option should be enabled out of the box.

Parag Chandra
Senior Software Developer
***@oracle.com
404-439-5821

-----Original Message-----
From: Markus Sinner [mailto:***@psitronic.de]
Sent: Wednesday, June 25, 2008 2:01 AM
To: eclipseme-***@lists.sourceforge.net
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.
That kind of problems always occur in eclipse if you delete folders NOT
using eclipse. If you go to resource view, update it (F5) and then try
again, it should work, because then eclipse "knows" about the current
filesystem. If not, I suggest opening a bugreport.

Thats very annoying about eclipse.

> 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).
I think all of us had similar problems :-)


--

*********************************
***@psitronic.de
http://www.psitronic.de

psitronic IT-Solutions
Markus Sinner
W-Rathenau-Str. 14 - 68642 Bürstadt
Tel.: (+49)6206 / 963513
Fax: (+49)6206 / 963514

-------------------------------------------------------------------------
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
Eclipseme-***@lists.sourceforge.net
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
Craig Setera
2008-06-29 12:17:27 UTC
Permalink
Parag,

You are seeing some of the Smalltalk-based heritage of the Eclipse
tooling with the refresh necessity. For those of us that grew up
through those tools, this isn't so hard to deal with, although it is
annoying at times. I think they will likely try to better address some
of this with the new "e4" effort that has begun for defining the next
generation of Eclipse tooling.

Craig

***@ORACLE.COM wrote:
> I wonder if enabling this option:
>
> Window...Preferences...General...Workspace...Refresh automatically
>
> would let EclipseME know that the directory had been deleted? Until I discovered this option last week, my biggest complaint about Eclipse vs. Visual Studio was that the entire Package Explorer had to be manually refreshed any time you made changes outside of Eclipse. I feel like this option should be enabled out of the box.
>
> Parag Chandra
> Senior Software Developer
> ***@oracle.com
> 404-439-5821
>
> -----Original Message-----
> From: Markus Sinner [mailto:***@psitronic.de]
> Sent: Wednesday, June 25, 2008 2:01 AM
> To: eclipseme-***@lists.sourceforge.net
> 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.
>>
> That kind of problems always occur in eclipse if you delete folders NOT
> using eclipse. If you go to resource view, update it (F5) and then try
> again, it should work, because then eclipse "knows" about the current
> filesystem. If not, I suggest opening a bugreport.
>
> Thats very annoying about eclipse.
>
>
>> 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).
>>
> I think all of us had similar problems :-)
>
>
>

-------------------------------------------------------------------------
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
P***@ORACLE.COM
2008-06-24 21:30:39 UTC
Permalink
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.

Parag Chandra
Senior Software Developer
***@oracle.com
404-439-5821
-----Original Message-----
From: Berk Birand [mailto:***@superonline.com]
Sent: Tuesday, June 24, 2008 6:46 AM
To: eclipseme-***@lists.sourceforge.net
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 <***@psitronic.de>
>>> An: eclipseme-***@lists.sourceforge.net
>>> 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
>>>> Eclipseme-***@lists.sourceforge.net
>>>> 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
>>> Eclipseme-***@lists.sourceforge.net
>>> 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
> Eclipseme-***@lists.sourceforge.net
> 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
Eclipseme-***@lists.sourceforge.net
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
Berk Birand
2008-06-24 13:35:34 UTC
Permalink
***@ORACLE.COM 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
> ***@oracle.com
> 404-439-5821
> -----Original Message-----
> From: Berk Birand [mailto:***@superonline.com]
> Sent: Tuesday, June 24, 2008 6:46 AM
> To: eclipseme-***@lists.sourceforge.net
> 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 <***@psitronic.de>
>>>> An: eclipseme-***@lists.sourceforge.net
>>>> 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
>>>>> Eclipseme-***@lists.sourceforge.net
>>>>> 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
>>>> Eclipseme-***@lists.sourceforge.net
>>>> 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
>> Eclipseme-***@lists.sourceforge.net
>> 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
> Eclipseme-***@lists.sourceforge.net
> 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
> Eclipseme-***@lists.sourceforge.net
> 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
Setera Craig
2008-06-25 11:07:06 UTC
Permalink
Berk,

It sounds like you had an interesting combination of issues. If
EclipseME was working correctly, you should have received an error
marker in the Java editor. Any chance that you had it and didn't
notice? If not, there is likely a bug in EclipseME which definitely
made things more difficult for you to narrow down your problem.

I'm glad that you came to the mailing list and that you eventually
figured out your problem. Please feel free to create a bug report on
Sourceforge for anything that seemed to be wrong in EclipseME. While
it is unclear how many bugs I will fix directly in EclipseME, I will
make sure to work with everyone on the MTJ project to make sure that
these bugs are fixed in the MTJ code.

Thanks,
Craig

On Jun 24, 2008, at 8:35 AM, Berk Birand wrote:

> ***@ORACLE.COM 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
>> ***@oracle.com
>> 404-439-5821
>> -----Original Message-----
>> From: Berk Birand [mailto:***@superonline.com]
>> Sent: Tuesday, June 24, 2008 6:46 AM
>> To: eclipseme-***@lists.sourceforge.net
>> 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 <***@psitronic.de>
>>>>> An: eclipseme-***@lists.sourceforge.net
>>>>> 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
>>>>>> Eclipseme-***@lists.sourceforge.net
>>>>>> 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
>>>>> Eclipseme-***@lists.sourceforge.net
>>>>> 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
>>> Eclipseme-***@lists.sourceforge.net
>>> 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
>> Eclipseme-***@lists.sourceforge.net
>> 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
>> Eclipseme-***@lists.sourceforge.net
>> 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
> Eclipseme-***@lists.sourceforge.net
> 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
Setera Craig
2008-06-24 10:42:35 UTC
Permalink
I'm not sure what is going on, but I can say that messing with the
classpath probably isn't going to solve the problem. Have you done a
project Clean operation? The information on the builder logging can
be found in the EclipseME documentation at http://eclipseme.org/docs/buildingRef.html
.

Craig

On Jun 23, 2008, at 3:58 PM, Berk Birand wrote:

> 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
> Eclipseme-***@lists.sourceforge.net
> 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
Loading...