harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [classlib][luni] JIRA 1492 Constructor of HashMap throw unexpected exception
Date Wed, 20 Sep 2006 06:33:40 GMT
But we can create such test case for every difference in used methods
between RI and Harmony. Right?

2006/9/20, Paulex Yang <paulex.yang@gmail.com>:
> Alexey Petrenko wrote:
> > Are you trying to say that the methods in Harmony can use only methods
> > used in corresponding RI implementations?
> Let Spark speak for himself, but IMHO let's discuss the specific case
> before considering it as a rule, this is not yet another "reverse
> engineering", the testcase is clear, without injection or reflection,
> and the method under test is a constructor which invokes a public
> method, so that user may have risk cannot to init their subclass of
> HashMap.
> >
> > 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
> >>
> >>
> >
> >
>
>
> --
> 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
>
>


-- 
Alexey A. Petrenko
Intel Middleware Products Division
Mime
View raw message