Intransigent transient



  • public class XYZ {
    private XXX transientData;
    private transient XXX staticData;
    ...
    }

    ... Why ?!

     



  • @snoofle said:

    ... Why ?!
    Because I said so.



  • More digging revealed:

     

    public class SerializeStuff {
    public static String serializeXyz(XYZ xyz) {
    StringBuidler sb = new StringBuilder();
    //sb.append(xyz.getTransientData().toString()); // instance data
    sb.append(xyz.getStaticData().toString()); // transient data
    ...
    return sb.toString();
    }



  • So, the "dev" (notice the quotes) made a non-serializable field, serializable.

    [Fingers in power teepee] Excellent...

     

    Why the extra work to break\hack\workaround built-in functionality?  Just remove the transient modifer, no?



  • @C-Octothorpe said:

    Just remove the transient modifer, no?

     

    I can't modify this particular chunk of code, but I do need to use it. When I looked at the object after deserialization, the wrong (by any normal standard) set of fields was populated, and I just had to investigate as to why.

    It turns out the "dev" didn't want to change the "transient" status of the variable that yet another "dev" had written before him, so to be safe, he decided to handle it himself and wrote his own [de]serialization; instead of just using Serializable (think Externalizable: readExternal(), writeExternal()).

     


  • ♿ (Parody)

    @snoofle said:

    It turns out the "dev" didn't want to change the "transient" status of the variable that yet another "dev" had written before him, so to be safe, he decided to handle it himself and wrote his own [de]serialization; instead of just using Serializable (think Externalizable: readExternal(), writeExternal()).

    It's nice to see people thinking about breaking stuff whose full scope and rationale they do not understand. Of course, this solution is probably more of a WTF than simply making the change and breaking stuff. Reminds me of a G.K. Chesterton quote:
    @G.K. Chesterton said:

    In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

    I'm not sure how the dev in question fits into that metaphor.



  • @boomzilla said:

    I'm not sure how the dev in question fits into that metaphor.

    I think he saw the gate across the road, realised he didn't understand the use of it, so knocked a hole in the wall next to it - better safe than sorry.


Log in to reply