harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spark Shen" <smallsmallor...@gmail.com>
Subject Re: [classlib][beans]Non-bug difference in java.beans.Statement/Expression(HARMONY-4392)
Date Thu, 12 Jul 2007 03:25:49 GMT
I prefer to follow spec. I have record the issue as non-bug difference in
the wiki page I mentioned above.

2007/7/10, Alexei Zakharov <alexei.zakharov@gmail.com>:
>
> Hi guys,
>
> FYI here is a link to the 1 year old thread about the same issue:
>
> http://thread.gmane.org/gmane.comp.java.harmony.devel/11328
>
> However, it ended with nothing. As for me - I support your idea that
> we should take the most specific method / constructor.
>
> With Best Regards,
>
> 2007/7/9, Spark Shen <smallsmallorgan@gmail.com>:
> > As discussed before, I made a wiki page to record development progress
> in
> > beans module.
> > It is now at http://wiki.apache.org/harmony/ProgressInBeansModule.
> >
> > I suggest we record this non-bug difference there for a record.
> >
> > 2007/7/9, Yang Paulex <paulex.yang@gmail.com>:
> > >
> > > I raised HARMONY-4392 for your comments on a non-bug difference in
> > > java.beans.Statement/Expression. Basically the issue is seems RI's
> > > implementation cannot handle the overloaded constructor properly,
> which
> > > just
> > > finds the first usable one and invoke, while spec requires the most
> > > specific
> > > method should be found and used. Harmony actually works in similar way
> > > with
> > > RI now, but because this kind of implementation depends on the order
> of
> > > constructors found by reflection, they show different result now.
> Further,
> > > even RI 5 and 6 shows difference.  Please refer to JIRA for details.
> > >
> > > My opinion is to fix Harmony following spec, and RI's behavior is
> almost
> > > impossible to follow even if we want :). How do you think?
>
> --
> Alexei Zakharov,
> Intel ESSD
>



-- 
Spark Shen
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message