Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: unknown (idunn.apache.osuosl.org: domain gmail.com does not
 designate 202.81.18.152 as permitted sender)
Message-ID: <4511FC2B.3010507@gmail.com>
Date: Thu, 21 Sep 2006 10:42:51 +0800
From: Spark Shen <smallsmallorgan@gmail.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] JIRA 1492 Constructor of HashMap throw
 unexpected
 exception
References: <009501c6dd16$2fda9130$0201a8c0@LITTLEGUY>
In-Reply-To: <009501c6dd16$2fda9130$0201a8c0@LITTLEGUY>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-2022-JP

Nathan Beyer 写道:
> I'm still waiting to see a real and non-trivial piece of code that does
> this. Does anyone have one?
>
> I don't disagree with the various comments about class design, but this
> seems indicative of a larger problem with the entire implementation.
>
> -Nathan
>   
Hi Nathan:

Thank you for your agreement.  :-) 
Can I conclude that you do think this may be a design pitfall and will
bring potential problem.

Best regards

>   
>> -----Original Message-----
>> From: Andrew Zhang [mailto:zhanghuangzhu@gmail.com]
>> Sent: Wednesday, September 20, 2006 3:28 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][luni] JIRA 1492 Constructor of HashMap throw
>> unexpected exception
>>
>> Josh Bloch has given an excellent comment on this issue in his famouse
>> book "effective java", item 15  "Design and document for inheritance or
>> else
>> prohibit it".
>> [quote from "effective java"]
>> There are a few more restrictions that a class must obey to allow
>> inheritance. Constructors
>> must not invoke overridable methods, directly or indirectly. If this rule
>> is
>> violated, it is
>> likely that program failure will result. The superclass constructor runs
>> before the subclass
>> constructor, so the overriding method in the subclass will get invoked
>> before the subclass
>> constructor has run. If the overriding method depends on any
>> initialization
>> performed by the
>> subclass constructor, then the method will not behave as expected.
>> [/quote]
>>
>> So I'd like to agree with Paulex that we'd better fix this problem. :-)
>>
>>
>> On 9/20/06, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
>>     
>>> Are you trying to say that the methods in Harmony can use only methods
>>> used in corresponding RI implementations?
>>>
>>> 2006/9/20, Spark Shen <smallsmallorgan@gmail.com>:
>>>       
>>>> 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
>>     
>>>>> Spark
>>>>> 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
>>>>
>>>>
>>>>         
>>> --
>>> Alexey A. Petrenko
>>> Intel Middleware Products Division
>>>
>>>       
>>
>> --
>> Andrew Zhang
>> 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
>
>
>   


-- 
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