Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Message-ID: <4510EEB7.4050302@gmail.com>
Date: Wed, 20 Sep 2006 15:33:11 +0800
From: Paulex Yang <paulex.yang@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: <451096F0.4010207@gmail.com>
 <45109740.1010703@gmail.com>	 <c3755b3a0609192228i5c34a14cjfcf32c0a4dc7b9bb@mail.gmail.com>
	 <4510DF78.4020208@gmail.com>
 <c3755b3a0609192333u56d528c6yb6241b687f86db75@mail.gmail.com>
In-Reply-To: <c3755b3a0609192333u56d528c6yb6241b687f86db75@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Alexey Petrenko wrote:
> But we can create such test case for every difference in used methods
> between RI and Harmony. Right?
Sure we can:), I guess the issue is just if it is necessary. I've=20
described why I think it is necessary for HashMap's constructor in=20
another post of this thread -  HashMap is fundamental and widely used,=20
so it should be tolerant; constructor is special, so it should be taken=20
care of.
>
> 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 =E5=86=99=E9=81=93:
>> >> > Hi :
>> >> > Following is the discussion about JIRA 1492, shall we discuss it=20
>> here?
>> >> >
>> >> > public class SubMapTest extends TestCase {
>> >> > public void testSubclass() {
>> >> > HashMap map =3D new HashMap();
>> >> > map.put("a", "a");
>> >> > SubMap map2 =3D 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=20
>> sure I
>> >> > would consider this a valid issue. What's a real use case for this
>> >> > type of sub-classing?
>> >> > [ Show =C2=BB <http://issues.apache.org/jira/browse/HARMONY-1492> ]
>> >> > Nathan Beyer
>> >> > <http://issues.apache.org/jira/secure/ViewProfile.jspa?name=3Dnbeye=
r>
>> >> > [18/Sep/06 08:41 PM] Harmony's behavior may be different in this=20
>> 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?
>> >> >
>> >> >
>> >>=20
>> <http://issues.apache.org/jira/secure/ViewProfile.jspa?name=3Dspark+shen=
>>Spark=20
>>
>> >>
>> >> > Shen
>> >> > >What if change the RuntimeException to=20
>> UnsupportedOperationException?
>> >> > [ Show =C2=BB <http://issues.apache.org/jira/browse/HARMONY-1492> ]
>> >> > spark shen
>> >> >
>> >>=20
>> <http://issues.apache.org/jira/secure/ViewProfile.jspa?name=3Dspark+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=20
>> 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=20
>> 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 =3D new HashMap();
>> >> map.put("a", "a");
>> >> SubMap map2 =3D 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:=20
>> harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>>
>> --=20
>> 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
>>
>>
>
>


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