commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 15127] - Tests should explicit about checking serialization
Date Fri, 18 Apr 2003 22:07:53 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15127>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15127

Tests should explicit about checking serialization





------- Additional Comments From rwaldhoff@apache.org  2003-04-18 22:07 -------
I suppose I can understand the rationale for TestObject.isSerializable to
indicate "although this class claims to be serializable, it isn't", it's not
clear to me why we "objects should be tested for serializability even if they
don't implement the interface".  If your intention is to "[indicate] to the
developer that they should [implement serializable]", then why not make it
straightforward, put a test method like:

void testShouldBeSerializable() {
  assertTrue(makeObject() implements Serializable);
}

in the TextXxx class *for which you'd like to strongly suggest Serializablity*,
or put "implements Serializable" in the base Xxx class *for which you'd like to
_require_ Serializablity.

Your example of:

    List list1 = Collections.EMPTY_LIST
    List list2 = list1.subList(0, 0);
    List list3 = Collections.unmodifiableList(list2);

points to a bug in the Collections.umodifiableList method--the unmodifiable
version of a non-Serializable list should not be Serializable.

There is already a mechanism, crude as it may be, to prevent the serialization
tests from executing--override them with no ops.  Making it easier for a class
that implements Serializable to not actually be Serializable seems like a
questionable thing to me.  It'd be better for "implements Serializable" to mean
what it says.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message