Any chance gearing this rather useful package towards J2ME?

Well, the devs are currently very busy and at least me I have no J2ME experience yet. A patch would be welcomed though

Kinda busy at the moment, too, but I'll see what I can come up with.

As far as the 'java.version' is concerned, here is what Aonix tells me:
— quote —
"We have run into the java.version issue before. While it is true that
Sun licensed VMs offer a Sun-style version number string for
java.version, not all VMs do this. The J9 VM offers the string "1.3.0
subset", for example. When a VM has a subset of the libraries, it is
hard to know what value to offer and be safe. What we have tried to do
is consistently maintain the specification version number in the system
property "java.specification.version". For this property, Sun VMs return
"1.3", "1.4", or "1.5" depending on the release, of course. The j9 VM
returns "1.3" and PVM returns "1.3". Perhaps xtream could be persuaded
to use this property instead."
— quote —

Any chance using "java.specification.version" instead of "java.version"?

As far as the 'enhanced mode' goes, here is what the folks at Aonix offered
— quote —
"The xstream FAQ indicates that the "Enhanced" mode using Unsafe will
only work on Sun, Apple, and HP 1.4 VMs. As a clean room vendor, we
cannot look at Sun source code and cannot recreate a class that has no
publicly documented API. If xstream was willing to tell us what
functionality they need without revealing the source to Unsafe, we could
provide that functionality in PVM."
— quote —

Any chance you folks could tell me whats needed for 'enhanced' mode (vs. regular java mode) and I'll pass it on?

Thanks for the help

-Th

Hi Thomas,

I switched now internally from java.version to java.specification.version. For other VMs supporting enhanced mode we need two things
1) a proper way to identify the VM (should be trivial)
2) functionality to create an instance of a class without calling its ctor and the ability to set the fields even if final. THis is basically the same functionality each JDK must handle internally for serialization also.

• Jörg

Hi Jorg,

Does your last post indicate that we could now use XStream with say IBM's J9 VM, for J2ME environments?

Cheers,
Andrew.

Hi Andrew,

unfortunately, no. It just means, that XStream will now determin the JDK it is running on based on the entry of java.specification.version, which seems not filled with arbitrary elements as java.version. But XStream makes internal assumptions what classes are available for which JDK to register appropriate converters. This might not be true at all for J2ME and I have currently no setup with a test environment. So if you wanna give it a try and report back, it is more than welcome. I don't expect, that the enhanced mode will run though, this too specific for the Sun JDK.

• Jörg

XStream no longer fails for unavailabe converters during setup, available in trunk. However, since I have no test environment, any further problem must be reported in a new issue.