Affects Version/s: None
Fix Version/s: 1.4.5
JDK version and platform:Aonix PERC(R) VM 4.2.0451 Platform: [QNX 6.3.1]
Seems this package is something useful to alot of application profiles. Any chance to make this work with j2me profiles and embedded jvm's?
When testing on the Aonix PERC VM, it stalls at first on the dependency of the PERC format of "java.version" (which I will take to Aonix, they need to fix their non-standard version format).
The main obstacle, tho, is that XStream seems to want a full J2SE environment:
In class 'XStream.java' it wants to load converters that need javax.swing, javax.sql, java.io.File etc. Any chance of making loading those converters dynamic? I.e. don't bother with the converter if the extension package(s) doesn't exist - the classes won't exist and hence don't need a converter.
For J2ME/embedeed profiles, I think its safe to assume existence of data types, reflection (incl. dyn. proxies) and collections, anything beyond is fair game (just my observation).
Thanks for consideration,
- relates to
XSTR-566 AppEngine Compatibility.
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:
"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."
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
"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."
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
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.
Does your last post indicate that we could now use XStream with say IBM's J9 VM, for J2ME environments?
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.
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.
Well, the devs are currently very busy and at least me I have no J2ME experience yet. A patch would be welcomed though