Hi, On Sat, 2005-02-19 at 08:32 -0600, Michael Koch wrote: > On Fri, Feb 18, 2005 at 09:05:29PM -0600, Archie Cobbs wrote: > > I'm planning to commit this patch. The reason for it is that the > > logic of initCause() is unnecessary in the constructor, and represents > > unnecessary overhead which we pay for every time a chained exception > > is created. The effect is especially exacerbated when the constructor > > invocation is inlined at every instantiation site, bloating code size.
Seems sane to me. Is the instruction overhead really noticable/measurable to you? > > Note that initCause() is not final, so a subclass could override it; > > however the constructor does not specify that it calls initCause() to > > initialize the cause so this doesn't change any specified behavior. > > > > 2005-02-19 Archie Cobbs <[EMAIL PROTECTED]> > > > > * java/lang/Throwable.java: simplify initializing cause in constructor > > I think it would be best to test the behavior of latest SUN JDK and then > act on this. If it calles initCause() we need to do this too. If not we > should not too. Archie is right in his analysis and I also cannot find any documentation about any of the constructors ever calling initCause(). You really cannot demand that others to use any proprietary implementation while working on GNU Classpath. If you have actual free software programs that require a specific behavior please report to the list though. Then, if you must, you are also free to test what other implementations actually do and report your findings if you think they are relevant to decisions we make about our implementation. But in general people are not expected and explictly discouraged to rely on any proprietary software while working on GNU Classpath Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
