harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib][luni] JIRA 1492 Constructor of HashMap throw unexpected exception
Date Thu, 21 Sep 2006 02:50:11 GMT


> -----Original Message-----
> From: Spark Shen [mailto:smallsmallorgan@gmail.com]
> Sent: Wednesday, September 20, 2006 9:39 PM
> To: harmony-dev@incubator.apache.org
> 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: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


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