Details
-
Type:
New Feature
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.4.5
-
Component/s: None
-
Labels:None
Description
In my world of J2EE schemas all the enumerations are in camel case such as....
<xsd:complexType name="trans-attributeType">
<xsd:simpleContent>
<xsd:restriction base="javaee:string">
<xsd:enumeration value="NotSupported"/>
<xsd:enumeration value="Supports"/>
<xsd:enumeration value="Required"/>
<xsd:enumeration value="RequiresNew"/>
<xsd:enumeration value="Mandatory"/>
<xsd:enumeration value="Never"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
...or are contain illegal java characters like...
<xsd:complexType name="cmp-versionType">
<xsd:simpleContent>
<xsd:restriction base="javaee:string">
<xsd:enumeration value="1.x"/>
<xsd:enumeration value="2.x"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
This patch allows me to alias them into Java standard enum names such as...
xstream.aliasEnum(TxAttribute.NOT_SUPPORTED, "NotSupported");
xstream.aliasEnum(TxAttribute.SUPPORTS, "Supports");
xstream.aliasEnum(TxAttribute.REQUIRED, "Required");
xstream.aliasEnum(TxAttribute.REQUIRES_NEW, "RequiresNew");
xstream.aliasEnum(TxAttribute.MANDATORY, "Mandatory");
xstream.aliasEnum(TxAttribute.NEVER, "Never");
xstream.aliasEnum(TxType.BEAN, "Bean"):
xstream.aliasEnum(TxType.CONTAINER, "Container"):
xstream.aliasEnum(CmpVersion.CMP1, "1.x");
xstream.aliasEnum(CmpVersion.CMP2, "2.x");
... or even better on an enum type basis using an EnumFormat...
xstream.aliasEnumType(TxAttribute.class, new CamelcaseEnumFormat());
xstream.aliasEnum(TxType.class, new CamelcaseEnumFormat()):
xstream.aliasEnum(CmpVersion.CMP1, "1.x");
xstream.aliasEnum(CmpVersion.CMP2, "2.x");
... or better yet, specifying what I want the default to be ...
xstream.setDefaultEnumFormat(new CamelcaseEnumFormat());
xstream.aliasEnum(CmpVersion.CMP1, "1.x");
xstream.aliasEnum(CmpVersion.CMP2, "2.x");
... and you can alway implement your own EnumFormat if you just don't feel like maintaining direct aliases ...
xstream.setDefaultEnumFormat(new CamelcaseEnumFormat());
xstream.aliasEnumType(CmpVersion.class new MyDottedVersionNumerEnumFormat());
The one caveat to all this is that the methods aliasEnum, aliasEnumType, setDefaultEnumFormat and the interface EnumFormat all require Java 5 and sneaking around that just won't result in a nice API. I can't imagine people in 1.5 being happy with loosely typed methods like aliasEnum(Object, Object) or people in 1.4 having to learn that those aren't methods they can call. So I have subclassed XStream as XStreamTiger and exposed the Enum aliasing support there. Clearly, this is not desired as great lengths have obviously been taken to support all JDK versions with just the one XStream class, but it may be the lesser of two evils; the other evil being providing api support for enums that is on par with other java-isms like classes, fields, and collections while simultaneously pretending they don't exist by abstracting them out of the main XStream API.
Activity
Hi Jörg!
We switched away from XStream a couple months after this in OpenEJB (now TomEE) for JAXB and in fact have recently switched from that to a custom JAXB runtime we wrote that actually bytecode generates the (un)marshallers so no calculation is done at runtime all xml->java and java->xml logic is 100% static methods and quite fast as a result.
But I have been in your shoes more times than I can count and fully understand it isn't always easy to deal with the more complex patches that come in, due to time or other factors, and sometimes they hang over your head. I think it's wonderful to see you still working on XStream and I really appreciate the follow up. Few people would look so far back and take care of an issue like this and I think it shows great character.
David Blevins
added a comment - Hi Jörg!
We switched away from XStream a couple months after this in OpenEJB (now TomEE) for JAXB and in fact have recently switched from that to a custom JAXB runtime we wrote that actually bytecode generates the (un)marshallers so no calculation is done at runtime all xml->java and java->xml logic is 100% static methods and quite fast as a result.
But I have been in your shoes more times than I can count and fully understand it isn't always easy to deal with the more complex patches that come in, due to time or other factors, and sometimes they hang over your head. I think it's wonderful to see you still working on XStream and I really appreciate the follow up. Few people would look so far back and take care of an issue like this and I think it shows great character. Hi David,
thanks for the feedback. I was aware that you're certainly no longer waiting for this functionality. And you're definitely right to use JAXB for your use case - especially if you generate byte-code on the fly, this sounds interesting 
Jörg Schaible
added a comment - Hi David,
thanks for the feedback. I was aware that you're certainly no longer waiting for this functionality. And you're definitely right to use JAXB for your use case - especially if you generate byte-code on the fly, this sounds interesting 
It's been a long time and XStream is still Java 1.4 compatible.
However, I was never lucky with the proposed changes of the XStream API. I've added therefore a complete different approach using a specialized converter (EnumToStringConverter) that can be registered individually for an individual Enum type. By default it is using the Enum's string representation (that's what I normally use to get a nice camel case representation from enum values like NOT_SUPPORTED also in other parts of my applications) or you may provide an individual map for the string alternative values.
This functionality works in consequence like an alias support for Enum values. Aliasing an Enum type has been possible for quite some time ago.