XStream

Any chance gearing this rather useful package towards J2ME?

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: Upcoming
  • Component/s: None
  • Labels:
    None
  • JDK version and platform:
    Aonix PERC(R) VM 4.2.0451 Platform: [QNX 6.3.1]

Description

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,

-Th

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. XSTR-566 AppEngine Compatibility.

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jörg Schaible added a comment -

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

Show
Jörg Schaible added a comment - Well, the devs are currently very busy and at least me I have no J2ME experience yet. A patch would be welcomed though
Hide
Permalink
Thomas Hentschel added a comment -

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

Show
Thomas Hentschel added a comment - 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
Hide
Permalink
Jörg Schaible added a comment -

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
Show
Jörg Schaible added a comment - 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
Hide
Permalink
Andrew Rothwell added a comment -

Hi Jorg,

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

Cheers,
Andrew.

Show
Andrew Rothwell added a comment - Hi Jorg, Does your last post indicate that we could now use XStream with say IBM's J9 VM, for J2ME environments? Cheers, Andrew.
Hide
Permalink
Jörg Schaible added a comment -

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
Show
Jörg Schaible added a comment - 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

People

  • Assignee:
    Unassigned
    Reporter:
    Thomas Hentschel
Vote (2)
Watch (2)

Dates

  • Created:
    Updated: