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 <[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:
[EMAIL PROTECTED]
>>
>>
>
>
--
Paulex Yang
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]
