MIDlet won't work anymore | Telit Cinterion IoT Developer Community
October 27, 2021 - 2:57pm, 5603 views
Hello,
month ago I formatted my computer and later installed Netbeans and all that is needed for development of BGS5T MIDlets.
Betwen that time and today I had updated one project and successfully installed MIDlet on BGS5T. Today I made some changes to another MIDlet that is on around 500 devices. When I run the MIDlet it crashed soon after statup:
java.lang.NoClassDefFoundError: az
- java.lang.Class.initialize(), bci=69
- bh.<init>(), bci=21
- inpro_all_in_one.IMlet.<init>(), bci=488
- java.lang.Class.newInstance(), bci=0
- com.sun.midp.main.CldcMIDletLoader.newInstance(), bci=69
- com.sun.midp.midlet.MIDletStateHandler.createMIDlet(), bci=63
- com.sun.midp.midlet.MIDletStateHandler.createAndRegisterMIDlet(), bci=17
- com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=24
- com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=38
- com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=5
- com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=134
- com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
MIDlet:inpro_all_in_one.IMlet abnormal exit
MIDlet:inpro_all_in_one.IMlet abnormal exit
Something similar somthing happens to the modules that are long in the field. So I tried to use gWinSwup to reinstall the JRC, since this usaly helps. But in this case it didn't help. So I check if I maybe have some error in my MIDlet but I coulden't find it. I tried loading two older versions of my software that are on atleast 200+ modules and I got same error.
After that I tried to load the MIDlet on another module but I got same error. What could be the cause for this? I tried running some other MIDlets and they run fine. Could be that after first instalaiton of the MIDlet and then when I delted it some files were still perserved and are affecting older versions?
Last module that I tested it is
ati1
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.10OK
The first module is:
ati1
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.001.37OK
Regards,
Jure
Hello Jure,
Do you obfuscate the MIDlet? The line "java.lang.NoClassDefFoundError: az" seems to suggest that the class named "az" cannot be found. Please do not obfuscate the class extending MIDlet.
BR,
Bartłomiej
Hello Bartlomiej,
this are my obfuscate settings:
Obfuscator arguments:
-dontusemixedcaseclassnames
-defaultpackage ''
-overloadaggressively
-keep public class ** extends javax.microedition.midlet.MIDlet {
public *;
}
Do you maybe know what should I add? I am using this for a few years and I haven't had any problems.
Regards,
Jure
Hello Jure,
I don't have much experience with obfuscation. Your configuration seems correct with regard to MIDlet class. But please also see here: https://iot-developer.thalesgroup.com/tutorial/optimising-j2me-applications
Please also decompile the obfuscated MIDlet and check if the main class is not obfuscated. Please also find 'az' class and see which class it is.
But first please build the MIDlet without obfuscation for test and run it (if possible, i.e. if the MIDlet is not too big) to verify if the problem really is related to obfuscation.
BR,
Bartłomiej
Hello Bartłomiej,
I check .jar file and I see that main class still has the original name. I tried to decompile the "az" class and it is probably from BouncyCastle libratay:
If I build MIDlet without obfuscation or just partial obfuscation it's to big (2500 kb) I can transfer it to BGS5T, but I can't install it.
I tried different obfscuation configurations but I didn't had any success. I tried to obfscucate trough standalone Proguard application, but I can't install MIDlet then.
Is it posible that there is to many classes because last working version which like mentioned can't be installed anymore when new version is installed has less classes. But until I change some config files, new classes aren't even run.
Regards,
Jure
Hello,
It is quite strange. Was this file in the previous version too? Have you updated the BouncyCastle library? I don't think that it could be too many classes but you could always try to remove the unused ones.
The obfuscator should create a map where you should be able to check what class 'az' is. And then you could try not to obfuscate this one too for test.
Maybe you'll observe some other error then.
BR,
Bartłomiej
Hello,
I changed the obfuscation so that classes names stay the same. Class in problem is from my own library, which was last changed in 14.5.2020.
START OF IMLET ALL IN ONE
LoadNeededObjects
debugLogger
opening FileConnection... shareData.txt
closing fc... shareData.txt
java.lang.NoClassDefFoundError: coreb.DebugLogger$Loader
- java.lang.Class.initialize(), bci=69
- coreb.LaunchControl.<init>(), bci=27
- inpro_all_in_one.IMlet.<init>(), bci=190
- java.lang.Class.newInstance(), bci=0
- com.sun.midp.main.CldcMIDletLoader.newInstance(), bci=69
- com.sun.midp.midlet.MIDletStateHandler.createMIDlet(), bci=63
- com.sun.midp.midlet.MIDletStateHandler.createAndRegisterMIDlet(), bci=17
- com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=24
- com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=38
- com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=5
- com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=134
- com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
MIDlet:inpro_all_in_one.IMlet abnormal exit
MIDlet:inpro_all_in_one.IMlet abnormal exit
And there is still a problem, that I can't install older version of MIDlets.
Regards,
Jure
Hello Jure,
If this class is really present in the jar file (which you have proved as I understood) you can still try to exclude the whole class from obfuscation and see what happens.
The other thing I can think of is that maybe the class files are created for the wrong version of Java. As you have the new OS and maybe you also set up the new project from the old sources maybe your project is not configured correctly. I currently don't have NetBeans installed and I don't usually use it but in Eclipse there is a setting in the project configuration where you set the compiler compliance level which should be 1.3. If the class files are generated for Java 1.4 for instance I suppose that such an error could also happen in some cases.
Best regards,
Bartłomiej
Hello Bartłomiej,
yes class is present.
When building jar I get warrning, probably from pro guard:
So it is probably building for correct Java version. I don't know what else I could try, I will try to delete Netbeans, Java and install them again.
Regards,
Jure
Reinstall didn't help.
Regards,
Jure
Hi Jure,
I'd rather try to create the new project, moe the code there and try. Or create the test project that only uses the code in question.
BR,
Bartłomiej
Pages