Lightweight peer implementation

[Bryce McKinlay]

On Saturday, Aug 9, 2003, at 15:27 Pacific/Auckland, Thomas Fitzsimmons 
wrote:

> 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 
>> back.
>> http://gcc.gnu.org/ml/java-patches/2003-q2/msg00140.html

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
> heavyweight.

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?

Regards

Bryce.