harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib][luni] JIRA 1492 Constructor of HashMap throw unexpected exception
Date Wed, 20 Sep 2006 06:23:47 GMT
Nathan Beyer wrote:
> Another assertion that the constructor does call "put" in Harmony and
> doesn't in the RI is only convincing of the fact that the implementation of
> the RI doesn't use public methods.
>   
Agreed that we don't need to follow RI's stacktrace in most cases, but,
if it shows different behavior to user, it's another story. This case is
about constructor, it is often dangerous to invoke overridable methods
in constructor if not by intention. If subclass override that method and
used some private field, the instance even cannot be inited at all.
> Do you have any actual use case that does this? I don't see the practicality
> of doing this. The HashMap javadoc doesn't guarantee this behavior and the
> examples for extending Map behavior is to wrap a Map, like in
> Collections.unmodifiableMap(Map).
>   
Javadoc doesn't guarantee this, but RI's behavior is logical and more
robust here, as Harmony's classlib compatibility guideline[1].

About composition vs. inheritance issue, I believe most of us have
consensus on which is better on when, but we cannot assume all our users
think in same way with us, if they failed to inherited HashMap for some
reasons, they just say: "Harmony is not so robust than Sun's JDK". About
actual use case, I have no real application now, but I can image many
possible reason to inherit HashMap in seconds, for example, some may not
happy to use an Entry array as backend, or they may want to record
something when put/get, or they may want to improve the performance of
putAll(), there may be better alternatives except inheritance, but it
should be the user's decision, not us. And I have a unrelated real case
on how to use HashMap, from a widely used OSS project, it reuse one
instance as key of HashMap by modifying hashCode()'s return value, it's
definitely bad, it works on RI but failed on Harmony, it took me several
hours to find the cause, but I'm lucky, how would a user do if his
commercial application fails on Harmony because of this? In this real
case, I even think Harmony has more reasonable behavior than RI, but I
learned the lesson again - never assume how user would use library.

After all, if we can make our codes more robust with almost no cost, why
not?

[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
> -Nathan
>
>   
>> -----Original Message-----
>> From: Spark Shen [mailto:smallsmallorgan@gmail.com]
>> Sent: Tuesday, September 19, 2006 8:20 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][luni] JIRA 1492 Constructor of HashMap throw
>> unexpected exception
>>
>> Spark Shen 写道:
>>     
>>> Hi :
>>> Following is the discussion about JIRA 1492, shall we discuss it here?
>>>
>>> public class SubMapTest extends TestCase {
>>> public void testSubclass() {
>>> HashMap map = new HashMap();
>>> map.put("a", "a");
>>> SubMap map2 = new SubMap(map); // Harmony will throw an unexpected
>>> exception here.
>>> }
>>> }
>>>
>>> class SubMap<K, V> extends HashMap<K, V> {
>>>
>>> public V put(K key, V value) {
>>> throw new RuntimeException();
>>> }
>>> }
>>>
>>>
>>>       
>>>> Nathan Beyer
>>>> Harmony's behavior may be different in this case, but I'm not sure I
>>>>         
>>> would consider this a valid issue. What's a real use case for this
>>> type of sub-classing?
>>> [ Show ≫ <http://issues.apache.org/jira/browse/HARMONY-1492> ]
>>> Nathan Beyer
>>> <http://issues.apache.org/jira/secure/ViewProfile.jspa?name=nbeyer>
>>> [18/Sep/06 08:41 PM] Harmony's behavior may be different in this case,
>>> but I'm not sure I would consider this a valid issue. What's a real
>>> use case for this type of sub-classing?
>>>
>>>
>>>       
>> <http://issues.apache.org/jira/secure/ViewProfile.jspa?name=spark+shen>>Sp
>> ark
>>     
>>> Shen
>>>       
>>>> What if change the RuntimeException to UnsupportedOperationException?
>>>>         
>>> [ Show ≫ <http://issues.apache.org/jira/browse/HARMONY-1492> ]
>>> spark shen
>>> <http://issues.apache.org/jira/secure/ViewProfile.jspa?name=spark+shen>
>>> [18/Sep/06 08:48 PM] What if change the RuntimeException to
>>> UnsupportedOperationException?
>>>
>>>       
>>>> Alexey Petrenko
>>>> I'm not sure that this is a valid issue to.
>>>> As far as I understood the issue is that Harmony calls put method in
>>>>         
>>> constructor while RI does not. Right?
>>>
>>>       
>>>> If so I do not see any issue here.
>>>>         
>> I can not figure out what RI does. And please refer to JIRA 839, it
>> reports similar use case.
>> My point here is
>> 1. we may not be able to predict how users will use our library.
>> 2. Users could guess our implementation w/o difficulty, which
>> contradicts the encapulation priciple.
>> So I prefer to follow RI on this behavior.
>>
>> When changing to UnsupportedOperationException, the use case is more
>> practical, since it is highly like that put operation is not supported.
>> But it seems not so practical that this sub-hashMap can not be
>> instantiated. May be one more assertion can convince you that this is bug.
>>
>> public class SubMapTest extends TestCase {
>> public void testSubclass() {
>> HashMap map = new HashMap();
>> map.put("a", "a");
>> SubMap map2 = new SubMap(map);
>> assertEquals(1, map2.size());
>> }
>> }
>>
>> class SubMap<K, V> extends HashMap<K, V> {
>> public SubMap(Map<? extends K, ? extends V> m) {
>> super(m);
>> }
>>
>> public V put(K key, V value) {
>> throw new RuntimeException();
>> }
>> }
>>
>> Best regards
>>
>> --
>> Spark Shen
>> China Software Development Lab, IBM
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>     
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message