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?
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:
I had figured out (just ahead of your reply) that the facility to transfer floats was the “problem”
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.
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 …
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.
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.
