powered by Jive Software

Smack and J2ME

Generally, I am impressed by smack; it really looks like the “right thing” to do!

I want to use “smack” on the J2ME platform; unfortunately, I am noticing the following error when compiling against smack using Sun’'s KToolbar dev kit (J2ME 1.0.4).

ERROR: floating-point arguments should not appear

Error preverifying class org.jivesoftware.smack.packet.Packet

com.sun.kvem.ktools.ExecutionException: Preverifier returned 1

I guess the next thing is for me to examine the code and think of a fix (is it really necessary to use floats?). Have you already noticed this problem and do you have a pending change to the library? If not, how do I submit my patch code to you?

Thanks in anticipation!

Colin,

Interesting, I didn’‘t know that floats weren’'t allowed by J2ME. The reason floats are in the packet class is because we allow them to be set as “packet properties”

/** * Sets a packet property with a float value. * * @param name the name of the property. * @param value the value of the property. */
public void setProperty(String name, float value) {
    setProperty(name, new Float(value));
}

I’'m not sure what the best solution would be. Is there anything else in Smack that causes problems on J2ME? If no, perhaps we can come up with a simple workaround for this case. Also, you may wish to replace the default XML parser used by Smack with a smaller one. You can find downloads of kXML2 at:

http://www.xmlpull.org/impls.shtml

If it all seems to work well, perhaps we can make a standard J2ME release.

Regards,

Matt

Thanks Matt.

I had figured out (just ahead of your reply) that the facility to transfer floats was the “problem”:wink:

I simply commeted out the relevant code as a temporary fix.

In packet.java:

/**

  • Sets a packet property with a float value.
  • @param name the name of the property.

  • @param value the value of the property.

*/

/**

  • @fixme

public void setProperty(String name, float value) {

setProperty(name, new Float(value));

}

*/

and later in the getPropertiesXML function:

/**

  • @fixme

else if (value instanceof Float) {

buf.append(“float”>").append(value).append("");

}

*/

This looks like it will do the trick to me. Perhaps the best solution is to add a new “J2ME” target to the ant build script to build a “smack_j2me.jar” without the offending float code?

It would be great if it built against a small footprint xmlpull implementation too; I have only got as far as downloading the various alternatives.

I have to come clean here, I am an ant newbie (only using it for 1.5 days), plus its the start of my weekend. I probably won’'t be able to do any more work on this until Monday, but it looks like its early morning for you so… (cheeky grin).

Obviously, if you don’'t have time to fix things then I will understand, and be happy to send you a copy of any modifications I make next week.

In the meantime, have a nice weekend!-)

Colin,

It sounds like this shouldn’‘t be too difficult. I’'ll see what I can do on it this weekend.

Regards,

Matt

Hmm… I checked through a bit of the J2ME documentation, and it appears double is not supported either?

Regards,

Matt

I am not sure which document you are looking at on Sun’'s site; I think the lowest common denominator for the current generation of phones & PDAs is the “Connected, Limited Device Configuration; Version 1.0a” (in the file cldc-1_0a-spec.zip).

As you will probably have noticed, Sun and partners are currently working on new Version 2 specifications for J2ME, but these are:

  • incomplete

  • not supported in the current generation of devices (although some might be flash-upgradeable I guess)

I have not really spent much time investigating the next generation as I am targeting what is currently available (namely the HP Jornado 920 series, in the first instance).

Anyway, the CLDC 1.0a spec lists the following Data Type classes as available:

java.lang.Boolean

java.lang.Byte

java.lang.Short

java.lang.Integer

java.lang.Long

java.lang.Character

Float and Double are (apparently) unavailable/missing. This makes sense I suppose; in the current generation of CDLCs, CPUs are likely to be missing hardware support of floating-point operations, and so it has been dropped from the JVM as well.

I am working on my own modifications to the smack source code/build process to produce a smack-j2me.jar which is compliant with CDLC 1.0a …

Colin,

The lack of support for Double means that a few Smack features would need to be changed/removed. For example, the ability to log into servers using password hashes. So, it’'s probably not feasable for us to provide official J2ME support in the library at this time, especially since so many features are in a state of flux.

However, if you’‘re willing to do the work of porting Smack to J2ME, we’'re happy to provide whatever help we can.

Regards,

Matt

Matt,

Wow, you certainly get up early to respond to queries in New York!!!

You are quite correct, there are a number of changes which would be necessary to get smack to play on J2ME.

I am currently considering the best way to proceed; my first instinct is to cut-down smack to fit J2ME …

Do you have any suggestions for how we could keep the code of the two libraries as closely synchronised as possible?

I am currently considering the best way to proceed;

my first instinct is to cut-down smack to fit J2ME

Do you have any suggestions for how we could keep the

code of the two libraries as closely synchronised as

possible?

It would be great to have a definitive list of what needs to be changed. Either way, I have a feeling it will be a somwehat difficult process to keep the codebases in sync until we have a stable 1.0 release. After that, changes will likely be small enough that it should be easy to maintain both versions.

Regards,

Matt