This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 72725 - J2ME Auto-Generated code starts new command listener thread each time app is pause/resumed
Summary: J2ME Auto-Generated code starts new command listener thread each time app is ...
Status: RESOLVED WONTFIX
Alias: None
Product: javame
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: David Kaspar
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-16 13:06 UTC by mrh30
Modified: 2006-10-23 16:41 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mrh30 2006-02-16 13:06:54 UTC 
Each time a J2ME application is either started, or restarted, startApp() is
called.  This in turn calls the auto-generated method initialize(). 
initialize() starts a new command listener thread (amongst other things). 
initialize() does not perform any checking however to see whether it is on
application start-up or on an application restart (for example after a telephone
call interruption is completed).  As a result, multiple command listener threads
are started, where there should only be one.

Suggest that the probable resolution is either to add code to the pauseApp()
method (or a derivative) to pause or kill the command listener thread, or put a
check in initialize() to test whether the application is doing a start, or a
restart.
Comment 1 Martin Brehovsky 2006-02-16 14:38:05 UTC 
There are two problems associated with this issue: the first one is the fact we
don't differentiate between start and restart of the application. This is known
problem and we plan to fix it in the future releases by introducing more
sophisticated model of the MIDlet lifecycle.

The other problem deals with the fact of starting new command listener thread -
this happens only if you are using "generated threaded command listener"
functionality. This functionality has been made deprecated in 5.0 and everyone
should be using rather new custom component called WaitScreen to perform
blocking task on the background (e.g. network communication) instead.

Since the "generated threaded command listener" has been deprecated in 5.0 and
we plan to drop this feature in the future releases completely, I'm sorry, but
this bug won't be fixed.