Agree.
And I think besides Constructors, we could also let clone and
de-serialization methods follow this rule, because they're also about
initialization of a object.
On 9/20/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
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: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
--
Andrew Zhang
China Software Development Lab, IBM
--
Robert Hu
China Software Development Lab, IBM
