Replacements for xstream?

General Discussions
#1

I’ve been using xstream to serialise objects to/from xml for my client-server communication. However despite what it’s documentation suggests, it doesn’t actually support running in the applet sandbox. >:(

Does anyone know of any alternative libraries that could work instead? Must be able to run in the applet sandbox as well as the google app engine sandbox (which is generally more lax than the applet one).

I guess I could also use regular serialisation? (rather than serialising to xml), I suspect that would cause maintenance and other issues that I’ve not realised yet. Plus I quite like having the transmitted data as human readable for debugging.

#2

i’m not sure if the following library does what you need but its suppose to be really good for what it does do (see benchmarks)

http://code.google.com/p/kryo/

not used the above library directly but can say though that its child library KryoNet is really nice also has really clean api and code.

#3

For a while at work I was using Xstream and ended up switching over to http://code.google.com/p/google-gson/
It doesn’t do XML, just JSON but I’d say it’s almost as configurable as Xstream goes for custom serialization and it seems to be faster/lighter-weight.

#4

Kryo seems to only serialise to/from binary? If so I don’t see what that gains me over regular serialisation.

gson looks nice, but some quick googling suggests it runs into the same problems as xstream when run in an applet. Is it known to work in the sandbox?

#5

What exactly is the Exception you run into with xstream (or gson for that matter).

if the problem is field.setAccessible(true), then maybe adding some getters/setters to access that field will be picked up by xstream. Needless to say I never did anything with xstream, so I’m just guessing.

#6

Sadly xstream makes the same mistake I initially did with Rebirth - it always calls setAccessible regardless of whether the field or method is already public. I’ve tried hacking the source but frankly it’s a mess and there are other, bigger issues lurking (like it trying to create classloaders, which also triggers a security exception in the sandbox).

#7

You could use java.beans.XMLEncoder and XMLDecoder which are in the standard jre

#8

Unfortunately I’d argue they fail on the ‘human readable’ requirement - the xml they produce is horribly obtuse and verbose. :frowning: