Compiling issues with WTK 2.5.2 (Sun Java Wireless Toolkit for CLDC)

[Simos Xenitellis]

Hi Arnold,

I am starting a new thread on WTK compiling. I will make some effort
to get the applet compile and work on WTK, as it is a simple
environment.
First of all, thanks for the instructions on the previous e-mail.

I am using the Sun Java Wireless Toolkit for CLDC,
http://java.sun.com/products/sjwtoolkit/
I run Ubuntu 64bit, and I use the 32bit version of the JDK (I am using
JDK 7 beta), because the WTK is 32-bit at the moment and the two have
to match.
I am able to run other applets from WTK, thus the environment appears
to be working well.

According to the WTK, I put any extra jar files in a lib/
subdirectory, in the project folder. I put there cldc_classes.zip and
cldc_crypto.zip.
Among the different combinations I tried, if I only put
cldc_classes.zip in lib/, then the project is able to compile.
I keep like that for now until I get some runtime error that something
from cldc_crypto.zip is missing.

Then, I am able to run the applet in the emulator. I get to the screen
that asks for Password twice.
I enter a password, and I then I press to Continue. At that stage I
get an exception,
«IOException reading reader invalid first byte 10101001»

The byte value appears to depend on the password. I put ASCII
characters for password.

Searching the web, it appears that such an exception is raised when
there are encoding issues in the source files.
My system locale and the locale in WTK (when the applet is running) is
UTF-8 ("Running with locale: en_US.UTF-8").
I checked all files in the current SMSSalama codebase and they all
appear to be UTF-8.
In fact there are no characters >127, thus they files are ASCII as well.

Simos

[Arpintim]

Thanks Simos,

I am not yet sure what is goin on there, but here is my take.

DataOutput.writeUTF() and DataInput.readUTF() are used when storing
and retrieving strings. After you enter the password twice, the
password hash is calculated and that is what is stored. But the hash
does contain non ASCII characters, and at the moment it is stored as
is. So this might be the source of the problem.

What I'll now do is convert the hash to a hex encoding, and then store
that hex encoding. Then we'll see if this solves the problem. If it
does solve it, then we may have another problem to deal with because
with UTF there should not be an issue when non-ASCII characters are
present.

Arnold.




On Jul 25, 3:47 pm, "Simos Xenitellis" <simos.li...@googlemail.com>
wrote:

> Hi Arnold,
>
> I am starting a new thread on WTK compiling. I will make some effort
> to get the applet compile and work on WTK, as it is a simple
> environment.
> First of all, thanks for the instructions on the previous e-mail.
>

> I am using the Sun Java Wireless Toolkit for CLDC,http://java.sun.com/products/sjwtoolkit/