This is the mail archive of the
mailing list for the Java project.
Re: Lightweight peer implementation
- From: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- To: Thomas Fitzsimmons <fitzsim at redhat dot com>
- Cc: Scott Gilbertson Onsite <sgilbertson-onsite at cogeco dot ca>,GCJ Patch List <java-patches at gcc dot gnu dot org>
- Date: Sun, 10 Aug 2003 16:13:00 +1200
- Subject: Re: Lightweight peer implementation
On Saturday, Aug 9, 2003, at 15:27 Pacific/Auckland, Thomas Fitzsimmons
On Fri, 2003-08-08 at 15:38, Scott Gilbertson Onsite wrote:
I claim that lightweights are not platform-specific, which is why I
submitted the following patch (which has not been comitted) a while
Yup, I agree. Lightweights should be implemented entirely in the
"generic" part of the code, not in the peer code.
I've adopted your approach and implemented some of the ComponentPeer
methods. I tried to copy the behaviour of the corresponding Component
calls when peer == null. My rational is that maybe we can eventually
remove the peer != null checks in Component.java, and assume that a
component always has a non-null peer, whether it be lightweight or
I think the null peer checks in Component are required because the
peers do not get created until the component is added to a container.
In the original thread, Tom mentioned that returning a gnu.java.awt
class from a java.awt class might not be a good idea. What about
implementing LightweightPeer as a private inner class of
Component.java? This approach would have the advantage that the peer
would have direct access to Component's fields.
I don't see a problem with returning a gnu.* class from getPeer(). Sun
calls it sun.awt.NullComponentPeer (obtained via getPeer().getClass())
so our name is analogous to that. Having direct access to the fields
would be nice (note that they are package-private), the problem of
course is that clients can override the get/set methods, and matching
the JREs behaviour with regard to what public methods it calls at what
times might be important to some (badly written) applications. Does
anyone have an idea on how much this matters in the real world?