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