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.
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)
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.
*** Issue 123883 has been marked as a duplicate of this issue. ***
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.
This issue is at least P2 because generated code is not compilable. UnsupportedOperationException is not part of CLDC/MIDP specification.
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.
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.
It looks like also JSR 177 Security and Trust Services APIs has UnsupportedOperationException implemented and is enabled in WTK configuration on default.
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? :-)
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.
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