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 82185 - Generate code for CLDC 1.0 and 1.1
Summary: Generate code for CLDC 1.0 and 1.1
Status: NEW
Alias: None
Product: javame
Classification: Unclassified
Component: JUnit (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: luky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-08 17:10 UTC by Lukas Hasik
Modified: 2008-05-06 11:35 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Hasik 2006-08-08 17:10:14 UTC
with the two versions of JMUnit library (for CLDC1.0 and CLDC1.1) it's possible
to use calls like assertEquals(boolean, boolean), assertEquals(double, double),
assertEquals(float, float). 

When user has more configurations in both CLDC1.0/CLDC1.1 in the project then
the generated test class has to be generated with preprocessor blocks.

e.g.
//#if CLDC=="1.0"
import jmunit.framework.cldc10.*;
//#else
import jmunit.framework.cldc11.*;
//#endif

and the right library has to be add to right configuration.
Comment 1 Jiri Prazak 2006-08-08 18:29:58 UTC
This is a lot more complicated than that.  Let's assume that the user creates
number of configurations but they all inherit from default configuration.  Later
the user generates tests.  The library gets added to all configurations as it is
now.  Then user decides to change one of the configurations from CLDC1 to CLDC11
so I have to listen on the change and replace the JAR. That is a big dependency
and a big change.

Even more problematic is the preprocessor because there is nothing preventing
the user from removing the CLDC ability from a list and then the code will
break.  The CLDC ability is not guaranteed.  We would need to implement
private/uneditable abilities for this to make sense.

I have to go and talk to some people who do this out there in the real world
because that is a lot of work for something that might never get used.
Comment 2 Lukas Hasik 2006-08-09 08:30:00 UTC
I agree it's complicated and we don't know usecases. That's why it is only P4
Comment 3 Lukas Hasik 2007-06-06 10:49:53 UTC
the general policy for issuezilla is "do not use the LATER/REMIND" resolution.
(http://qa.netbeans.org/bugzilla/issue-lifecycle.html).
These states are confusing and should be removed from issuezilla (unfortunately
colabnet doesn't know how to do it). Bug shouldn't be in RESOLVED state until it
is really resolved. IMO, that's not the case of LATER/REMIND.

Please, reevaluate the issue
1, When you don't plan to fix the issue close it as WONTFIX
2, you don't want to fix it now -> use TM=future

thank you for understanding