Is an error you might see when preverifying your midlet. Basically the problem is that the verifier can not find the referenced classes - and if it complains about java.lang.Object it basically can not find anything.
We had this today, and the reason was that our tool (IntelliJ) generated a not so good ant file, with the classpath for the jre. That is not what the preverifier expects. Rather it should be something like:
-classpath C:\WTK2.5.2\lib\cldcapi11.jar;C:\WC:\WTK2.5.2\lib\midpapi21.jar
Thursday, August 21, 2008
From applet to MIDlet
We have started to look into making a mobile client. Our current approach is to make a JME client, partly based on our existing Java client, based on Java SE and Swing and runnable as an applet or a standalone application. The rendering part will need to be rewritten but we hope to be able to reuse communication with the server and some of the internal logic.
Items we found so far:
Items we found so far:
- we use both socket and http communication. Both need to be rewritten to use the microedition Connector. So far the changes are small, but we will need to keep different classes for Java ME and SE versions
- we use gzip, in the SE version java.util.GZIPInputstream which is not included i Java ME
- enums is a big problem, looks like we will have to convert those used to old-fashioned int and classes with constant definitions.
- minor problems like String.split() (no such method in JME, and no StringTokenizer either) needs to be solved.
Subscribe to:
Posts (Atom)