• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

"Cannot create class in system package"

 
Jorma Ikonen
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Does anyone has ideas about the reason of above error on 7210 Nokia Emulator or real 7210 phone? My midlet (MIDP-1.0, CLDC-1.0) works fine in Sun's WTK104 emulator & 6650 phone and compiler or preverify-tool did not found any errors of it. Each used classes have been recompiled from the source by using bootclasspath-option.
Here are some "properties" of my midlet:
- uses BC's crypto-package (inc. java.security.SecureRandom)
- HttpConnection used.
- Hashtable, Vector, StringBuffers used.
- Jscience MathFP-package used.
- Threads used.
- Canvas, Form, ChoiceGroup, TextField used.
- Command, String, byte, boolean, etc. normal stuff used.
My guess is the "java.security.SecureRandom"-class, but can't be sure about that without modifying the code. Last time my problem was solved/replied during "extended lunch" and now weekend is coming...
Have a nice weekend!
br,
Jorma
 
Michael Yuan
author
Ranch Hand
Posts: 1427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Obfuscate your JAR file before deployment. The obfuscator will change the package names for you so that they do not appear to be from java.* namespaces.
 
Jorma Ikonen
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Use of obfuscator is a one way to solve the found problem (thanks about the tip, Michael!), but in practise someone else should be forced to correct their implementation of JVM... The specification is pretty clear and it says that user classes are not allowed to overwrite existing system classes, but my app is not doing that; It's extending system classes and what therefore should be allowed to do.
I thought that Java is platform independent programming language, but obviously this is a big joke. Of course, I have to obfuse/modify my code, but it's just not a right action. The right action would be to require the company correct their JVM to follow official spec. BTW, does Sun allow other companies to follow Gates way to add own "features" to JVM?
Yes, I'm angry about the situation, because this really do not make good for Java. I like Java, but "write once, debug everywhere" can't continue long time anymore. Current credibility is going below zero.
-Jorma-
 
Michael Yuan
author
Ranch Hand
Posts: 1427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm, I have not read the relevant part of the spec carefully. But SUN seems to admit that allowing user-supplied system packages in the WTK 1.xx is a mistake. In WTK 2.0, it is not permitted. Also, I know Motorola iDEN emulators do not allow this. So, to write portable code, you need obfuscate first.
 
David Price
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This was a detail that was too vaguely defined in the CLDC 1.0 specification, and much clarified in the CLDC 1.1 specification: you can't override, modify or add any classes to java.*, javax.microedition.*, profile-specific or manfufacturer-specific packages.
Nokia's phones have always implemented it this way, which means you'll need to use an obfuscator to change the package names if your MIDlet includes classes in e.g. java.* packages.
 
Jorma Ikonen
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is going to be a big mistake. Security can't base on naming policy and in a long run this decission will cause more problems as it solves:
- use of obfuscator in final product is always must to be sure about portability.
- reusability of obfuscated classes is history.
- programmers have to store obfuscated and non-obfuscated packages.
- portability between J2SE <-> J2ME goes harder and harder in future.
- phones might get own JIT obfuscators.
- etc.
This was a brilliant decission - Let's obfuscate everything!!!
-Jorma-
 
Michael Yuan
author
Ranch Hand
Posts: 1427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, the "system package" issue does not come up very often except for BC users. On the other hand, it is probably a good idea to obfuscate deployment applications anyway for the sake of reduced footprint. A good obfuscator should allow you to perserve public interfaces -- hence library reuse is not a problem.
As for J2SE -- J2ME portability, I guess this was never the design goal for J2ME. J2ME exists to break WORA. What matters is "skill portability" here.
Generally, I do not like obfuscators since they only keep out friendly eyes and give you a false sense of "security". But in the J2ME world, obfuscators and more generic code post-processors can squeeze the last bit of performance and hence are useful.
 
Jorma Ikonen
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks about your words , but still the decision was very stupid. Used namespace can't be security risk if the working principle of class loader of the JVM follows original spec:
1. first JVM searches required classes from own (system) packages.
2. If not found then JVM searches it from user package.
So, my common question is that how extended system classes can be a security risk? Does the VM really use package/class namespace as a part of permission policy?!? I thought that this issue was handled by certifications/signatures, but obviously JVM includes some non-public secrets...
Br,
Jorma
 
Kurinchikumaran Thavarajah
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for ur reply.

Yes I got the application work on the phone.

The problem is I had some packages with standard names including java. , javax. etc. After I changed all the names it works well with the phone.

But i'm using some already existing classes. so i want to have the original package names. What should i do to to have those packages with original name. It is a must for me.
 
Kurinchikumaran Thavarajah
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sorry for the wrong reply. it is not for this question
 
Aisling O' Driscoll
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Im fairly new to java/j2me development.I want to set up the sip api for j2me in jbuilder. However when i try to run the sample midlets that come with the api, I get the "cannot create class in system package" error. I realise from this post that I must "obfuscate" my classes. I would be very grateful if someone give me details of how I should do this in JBuilder?? I did a google serach and serached the jbuilder help files but have had no luck.

Hope to hear from someone,
BR,
Aisling
 
Peter Evans
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I just found this topic after searching for solutions to the "cannot create class in system package" error I get when trying to run a java application on my mobile. I have tried obfuscating the file myself but I'm not a programmer and thus completely failed.

Could anybody give me a very easy step by step method for obfuscating a .jar file? Or even better, do it for me if it would be easy for you! either reply on here, or get in touch via PM.

Thanks!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic