Runtime issues on Nokia devices and in Nokia's S40 and S60 emulators

[GoogleCodeExporter]

Currently when a J2ME application has been instrumented for code coverage
with JInjector, an unhandled exception is reported when running the
instrumented code on a device (e.g. the N95) or in both the S40 (6th
Edition) and S60 (3rd Edition Feature Pack 1) emulators.

We suspect the exception is related to getResourceAsStream() call which is
used to load the code coverage data file. 

We are investigating the cause and hope to publish an update this week.

Julian.

Original issue reported on code.google.com by julianharty on 9 Mar 2009 at 3:58

[GoogleCodeExporter]

This bug is caused by CoverageManager when it writes the coverage. This can 
happen
from two different locations. 

1) From the end of a J2ME test suite. This code will be removed and replaced 
with a
more accurate instrumentation.

2) From the instrumented code, if the used destination folder is not writable. 
This
will be fixed by locating a directory in which it will be possible to write.

Original comment by michele.sama on 11 Mar 2009 at 7:13

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have submitted an update that just *might* do the trick, at least on the S40
emulator and hopefully on the physical device(s). We discovered a subtle 
difference
in the way Nokia closes input streams for nested calls - it seems to close the 
parent
inputStream unlike the Sun WTK emulator. We've changed the code stop it 
propagating
an exception when it tries to close the parent inputStream. The update includes 
some
other minor changes to improve the logging of issues.

http://code.google.com/p/jinjector/source/detail?r=29 takes you to the update 
if you
want to see the changes, however hopefully all you'll need to do is an svn 
update in
your workspace and rebuild your project.

Note: When I tried the latest version on a Series 60 (a N95 phone) it does not 
seem
to create the coverage output file. I've been experimenting with some silly
workarounds e.g. to write the output to the photos directory but haven't 
managed to
convince the device to behave. However the example TimeMIDlet injected test now 
runs
correctly :) I need to update the example as well at some point as it doesn't 
have an
easy way to exit at the moment - I have a newer version that does but it's not 
in a
fit state to publish currently.

Original comment by julianharty on 11 Mar 2009 at 8:25