This is the mail archive of the
mailing list for the Java project.
Re: Lightweight peer implementation
- From: "Scott Gilbertson" <scottg at mantatest dot com>
- To: "Bryce McKinlay" <bryce at mckinlay dot net dot nz>,"GCJ Patch List" <java-patches at gcc dot gnu dot org>,"Thomas Fitzsimmons" <fitzsim at redhat dot com>
- Date: Tue, 12 Aug 2003 10:47:08 -0400
- Subject: Re: Lightweight peer implementation
- References: <0968DFD6-CC56-11D7-8F3E-003065F97F7C@mckinlay.net.nz>
> > Bryce wrote:
> >> Yup, I agree. Lightweights should be implemented entirely in the
> >> "generic" part of the code, not in the peer code.
> > Thanks, guys. I've been trying to get someone to express an opinion
> > one way
> > or the other on this issue for some time. I look forward to getting
> > the
> > lightweight components issue off my "pending" list.
> > I agree with all of what Bryce said:
> > - lightweights should be generic
> > - there should be no need to check for a null peer
> Well, I actually said there might be reason to check for null peer. In
> the JRE implementation, creation of the peers doesn't happen until the
> component is added to a container and/or its made visible. Just
> guessing - but this might be because some windowing systems don't allow
> the native widget to be created unless it already has a parent?
An alternative would be to have a single static instance of a "really
lightweight" peer, which returns nulls for everything, and make that the
Component's peer until the real one is set. You'd get a slight performance
boost, by eliminating a comparison statement in the common case where the
peer has already been set up (at least on architectures where a virtual
method call is faster than a conditional branch).