[xstream-user] Make UUID an Immutable type by default

[Geoff Groos]

Hey guys,

We’re just about to go to version 1.0, so I’m running over every piece of tech-debt I can think of to make sure all my ducks are in a row, and I found this in our project file (an XML serialized model):

<ProjectState.ImmutableMomento>
<associatedRunId>b723fec2-50f9-45fa-9a41-fee8d022b544</associatedRunId>
<!-- ... -->
</ProjectState.ImmutableMomento>
<ProjectState.ImmutableMomento>
<associatedRunId reference="../../ProjectState.ImmutableMomento/associatedRunId"/>

I cant think of a good reason for a UUID not to be immutable by default. Doing oneID == anotherID has to be as taboo as aString == anotherString to anybody whose willing to use a UUID object, meaning I don't think there’s any reason to preserve reference equality in serialization.

-Geoff

[Jörg Schaible]

Hi Geoff,

Post by Geoff Groos
Hey guys,
We’re just about to go to version 1.0, so I’m running over every piece of
tech-debt I can think of to make sure all my ducks are in a row, and I
<ProjectState.ImmutableMomento>
<associatedRunId>b723fec2-50f9-45fa-9a41-

fee8d022b544</associatedRunId>

Post by Geoff Groos
<!-- ... -->
</ProjectState.ImmutableMomento>
<ProjectState.ImmutableMomento>
<associatedRunId
reference="../../ProjectState.ImmutableMomento/associatedRunId"/>
I cant think of a good reason for a UUID not to be immutable by default.
Doing oneID == anotherID has to be as taboo as aString == anotherString to
anybody whose willing to use a UUID object, meaning I don't think there’s
any reason to preserve reference equality in serialization.

You're absolutely right. Can you open a JIRA ticket to track the issue,
please? Simply follow instructions at
http://xstream.codehaus.org/issues.html

Cheers,
Jörg

Sad to say, but 2 hours earlier, and it would already have been part of the
new release :-/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Geoff Groos]

Thanks Jörg,

I created an account but have run into some http:500s and what-not from jira while creating my account. I'll create the issue when I get all this stuff sorted out.

The second question I have, semi-related, is how would you guys suggest doing generational (ie cross-model-version) testing?

What I'd like to do is have tests like this:

public static class TestFixture{

public static class MyModel{ //v1
Public int x;
Public int y;
}

//And attempt to deserialize (using our moderately customized xstream serializer) it as

public static class MyModel{ //v2
Public int x;
Public int y;
Publix int z;
}

//in something like this
@Test
public void when_we_added_an_extra_int_field_for_feature_1234_we_didnt_break_anything_because_our_deserialization_flow_is_so_nifty(){
//setup
OurSerializerThatDelegatesToXStream serializer = testHarness.provideSerializer();

//act
String serialized = serializer.serialize(makeVersion1OfMyModel());
MyModel myModelV2 = serializer.deserialize(serialized);

//assert
assertThat(myModelV2.z).followsProperDomainLogic();
}
}

But of course Javac is going to complain about 2 'MyClass'es.

Any suggestions?

I was thinking about trying using 2 different canonical names (so MyClass1 and MyClass2), and then add an entry to the aliasMap as part of the setup logic to tell XStream that MyClass1 is-a MyClass2.

But since that doesn’t involve nearly enough overly complex code, the other thing I was thinking of doing is copy-pasting class files around and then manually loading via some stupidly sophisticated mechanism. With a couple extra ant targets I could probably even make this bearable.

Thanks for any help,

Geoff Groos, Lead Developer, Empower Operations Corp.
778 846 8593,
***@empowerops.com


-----Original Message-----
From: Jörg Schaible [mailto:***@gmx.de]
Sent: February 18, 2015 11:42 AM
To: ***@xstream.codehaus.org
Subject: [xstream-user] Re: Make UUID an Immutable type by default

Hi Geoff,

Post by Geoff Groos
Hey guys,
We’re just about to go to version 1.0, so I’m running over every piece
of tech-debt I can think of to make sure all my ducks are in a row,
<ProjectState.ImmutableMomento>
<associatedRunId>b723fec2-50f9-45fa-9a41-

fee8d022b544</associatedRunId>

Post by Geoff Groos
<!-- ... -->
</ProjectState.ImmutableMomento>
<ProjectState.ImmutableMomento>
<associatedRunId
reference="../../ProjectState.ImmutableMomento/associatedRunId"/>
I cant think of a good reason for a UUID not to be immutable by default.
Doing oneID == anotherID has to be as taboo as aString ==
anotherString to anybody whose willing to use a UUID object, meaning I
don't think there’s any reason to preserve reference equality in serialization.

You're absolutely right. Can you open a JIRA ticket to track the issue, please? Simply follow instructions at http://xstream.codehaus.org/issues.html

Cheers,
Jörg

Sad to say, but 2 hours earlier, and it would already have been part of the new release :-/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jörg Schaible]

Hi Geoff,

Thanks Jörg,
I created an account but have run into some http:500s and what-not from
jira while creating my account. I'll create the issue when I get all this
stuff sorted out.
The second question I have, semi-related, is how would you guys suggest
doing generational (ie cross-model-version) testing?
public static class TestFixture{
public static class MyModel{ //v1
Public int x;
Public int y;
}
//And attempt to deserialize (using our moderately customized xstream
serializer) it as
public static class MyModel{ //v2
Public int x;
Public int y;
Publix int z;
}
//in something like this
@Test
public void

when_we_added_an_extra_int_field_for_feature_1234_we_didnt_break_anything_because_our_deserialization_flow_is_so_nifty()
{

//setup
OurSerializerThatDelegatesToXStream serializer =
testHarness.provideSerializer();
//act
String serialized = serializer.serialize(makeVersion1OfMyModel());
MyModel myModelV2 = serializer.deserialize(serialized);
//assert
assertThat(myModelV2.z).followsProperDomainLogic();
}
}
But of course Javac is going to complain about 2 'MyClass'es.
Any suggestions?

Why don't you simply take the XML representation of model 1 and deserialize
it into model 2? Why do you still need to generate the XML representation of
model 1?

I was thinking about trying using 2 different canonical names (so MyClass1
and MyClass2), and then add an entry to the aliasMap as part of the setup
logic to tell XStream that MyClass1 is-a MyClass2.
But since that doesn’t involve nearly enough overly complex code, the
other thing I was thinking of doing is copy-pasting class files around and
then manually loading via some stupidly sophisticated mechanism. With a
couple extra ant targets I could probably even make this bearable.

The strategy to handle newer versions of a class depends on the type of
modification. There's no general rule.

See http://xstream.codehaus.org/faq.html#Serialization_newer_class_versions
for some ideas.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email