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 127179 - Mobility pack generates exceptions from JSE, and doesn't preverify output classes
Summary: Mobility pack generates exceptions from JSE, and doesn't preverify output cla...
Status: CLOSED WONTFIX
Alias: None
Product: javame
Classification: Unclassified
Component: Build System (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Karol Harezlak
URL:
Keywords:
: 123883 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-02-12 10:28 UTC by alexey_k
Modified: 2008-02-22 10:19 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description alexey_k 2008-02-12 10:28:11 UTC
Install Mobility pack, add WTK2.5.2 as new mobility platform.

Create new Mobility MIDP application, 
choose device configuration to CLDC1.1, device profiler to MIDP2.0
add "implements CommandListener" to Midlet.java description,
push on a hint "implement all abstract methods", the IDE adds 
"
    public void commandAction(Command arg0, Displayable arg1) {
        throw new UnsupportedOperationException("Not supported yet.");
    }
"
"UnsupportedOperationException" is not from MIDP spec. 
Moreover, and it's more important, I can run the Midle at the WTK!
If I manually preverify the classes
Error preverifying class hello.Midlet, I have an error:
VERIFIER ERROR hello/Midlet.commandAction(Ljavax/microedition/lcdui/Command;Ljavax/microedition/lcdui/Displayable;)V:
Cannot find class java/lang/UnsupportedOperationException
Which is correct. 

As a resume: 
1.Mobility pack creates applications which are not MIDP compliant 
2.WTK runs them with no problem. (I do not know now what the elulator emulate)
Comment 1 Karol Harezlak 2008-02-12 12:49:26 UTC
This issue is related to the editor so I'm going to reassigned to somebody from editor team. It's a problem with
generation of abstract methods. I agree that editor should not place UnsupportedOperationException in the new generated
method because it's not a part of CLDC or MIDP.
Reason why it worked in your case it's because UnsupportedOperationException is a part of the JSR 239 OpenGL ES (I
believe) and it is on the Classpath when you are using WTK 2.5.2. This JSR is part of the WTK 2.5.2 so thats why you
didn't get any exception or compilation error. Thanks for reporting this issue.  
Comment 2 Karol Harezlak 2008-02-12 13:28:15 UTC
*** Issue 123883 has been marked as a duplicate of this issue. ***
Comment 3 alexey_k 2008-02-13 07:55:54 UTC
has decreased the bug's priority. think it's a question of the WTK's usability.
I mean I can create a custom platform based on the WTK, choose only cldc11.jar, midpapi20.jar, configure preverify tool
and have VERIFIER ERROR before use my Midlets.

thanks for the answers.
Comment 4 Karol Harezlak 2008-02-21 19:12:48 UTC
This issue is at least P2 because generated code is not compilable. UnsupportedOperationException is not part of
CLDC/MIDP specification.
Comment 5 Jan Lahoda 2008-02-21 23:00:32 UTC
First, I though the method generator always generates the "throw" statement, so the fix would be not to generate it if
the j.l.UnsupportedOperationException wouldn't be on the CP. I have just checked the method generator, and it already
contains such a test. I do not see anything that could currently be done in Java editor to prevent generation of the
statement if the class is on the classpath - you probably need to make sure the class is not visible on the classpath.
Comment 6 Karol Harezlak 2008-02-22 05:10:46 UTC
Well it is not possible because when somebody using JSR 239 OpenGL ES then UnsupportedOperationException is on the
Classpath and has to be. In this case there is nothing we can do about. In scenario when user has enabled JSR 239 (not
on purpose) and generated code with UnsupportedOperationException then dist jar contains unsupported method and if user
try to run it on platform which doesn't support JSR 239 Midlet will fail. I have to agree that this behavior is correct
and user should correctly set up target platform environment. Closing as WONTFIX because solution like disabling JSR 239
in WTK configuration on default seems to be even worst and basically incorrect. 
Comment 7 Karol Harezlak 2008-02-22 05:42:13 UTC
It looks like also JSR 177 Security and Trust Services APIs has UnsupportedOperationException implemented and is enabled
in WTK configuration on default.
Comment 8 alexey_k 2008-02-22 08:33:07 UTC
Yep, it's a question of usability.
"Platform detection" mechanism does not allow me to chose what optional packages might be used if I choose WTK, it adds
all implemented JSRs... It does allow me to do that if I use mobility pack with WTK2.1 on Solaris, guess now it's "fixed". 

>First, I though the method generator always generates the "throw" statement, so the fix would be not to generate it if
>the j.l.UnsupportedOperationException wouldn't be on the CP.
Who do need such generator if MIDP clearly says there is no any Exception in the method? :-)
Comment 9 Karol Harezlak 2008-02-22 09:04:42 UTC
Unfortunately generation of UnsupportedOperationException is done by java editor module not by Mobility and same editor
is shared through all plugins thats why in most of the cases it OK. The question is if we need such w behavior in Java
Editor at all. 
Comment 10 Lukas Hasik 2008-02-22 10:19:34 UTC
WTK - is a generic emulator with reference implementation of the Java ME JSRs. All the JSR are enabled in the WTK
platform by default. *It is up to user to modify the platform settings to mimic his/her target platform*. This problem
won't appear when you are using a "real" SDK from a real vendor. 

Anyway, thank you for the report!

The IDE generates code like this
    private void testWitOut() {
    }
when there is no UnsupportedOperationException on class path.

Note: UnsupportedOperationException  must be somewhere else. Disabling JSR177 + OpenGL wasn't enough