Nathan Beyer 写道: > >> -----Original Message----- >> From: Spark Shen [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 20, 2006 9:39 PM >> To: [email protected] >> Subject: Re: [classlib][luni] JIRA 1492 Constructor of HashMap throw >> unexpected exception >> >> Hi Nathan: >> 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. >>> >>> >> Thank you for your agreement. :-) >> Can I conclude that you do think this may be a design pitfall and will >> bring potential problem. >> > > Yes, but I'd expect the issue to expand in scope and any patches to address > more than just the constructor. > +1
> -Nathan > >> Best regards >> >>> -Nathan >>> >>> >>> >>>> -----Original Message----- >>>> From: Andrew Zhang [mailto:[EMAIL PROTECTED] >>>> Sent: Wednesday, September 20, 2006 3:28 AM >>>> To: [email protected] >>>> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: >>>>> >>>>> >>>>>> 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: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: harmony-dev- >>>>>> >> [EMAIL PROTECTED] >> >>>>>> >>>>>> >>>>> -- >>>>> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >> -- >> Spark Shen >> China Software Development Lab, IBM >> >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Spark Shen China Software Development Lab, IBM --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
