Lightweight peer implementation

[Scott Gilbertson]

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
 - returning a gnu.* class from java.* is done in many other places, so it's
OK here
 - it's best not to give the lightweight peer special access to Component
fields

Bryce wrote:
> Does anyone have an idea on how
> much this matters in the real world?
I think that whenever get/set operations are available and not final, you
are obliged to use them, even if you're not sure whether it matters in the
real world.  If something is allowed, you've got to assume someone will do
it.  When I'm subclassing Component in an application, I don't hesitate to
override whatever method I think will get the job done.  Of course "get"
methods are kind of special that way, but if Sun says they're overridable,
so be it.

Thomas wrote:
> > 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.
Looking through Component.java, I think nearly all instances of "if (peer !=
null)" can be removed without doing anything in GLightweightPeer.  The only
exceptions I've noticed are things requiring the Toolkit (checkImage, for
example).  Since GLightweightPeer is constructed in Toolkit, the constructor
can simply accept a Toolkit as a parameter, so Toolkit.createComponent does:
  return new gnu.java.awt.GLightweightPeer (this);

There are some places where Component does two checks: (1) is the peer
non-null and (2) is the value returned from the peer non-null.  The second
check would have to stay, in these cases.

Should I get my earlier patch comitted first, so that you can submit just
the peer method implementations and Component simplifications, or do you
think it's easier to have you take over the whole issue?


----- Original Message ----- 
From: "Bryce McKinlay" <bryce@mckinlay.net.nz>
To: "Thomas Fitzsimmons" <fitzsim@redhat.com>
Cc: "Scott Gilbertson Onsite" <sgilbertson-onsite@cogeco.ca>; "GCJ Patch
List" <java-patches@gcc.gnu.org>
Sent: Sunday, August 10, 2003 12:13 AM
Subject: Re: Lightweight peer implementation


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