Anthony Magee <email@hidden> wrote:
> Java defined the AWT when it was very early in age, so the
>java code eventually calls some native code to draw its windows and
>so on. This is controlled by the JVM. Heavyweights, while not exactly
>the same on every system, do show the same characteristics of being
>drawn by native code and not interacting well with pure java --
>lightweight-- components.
Lightweight Components also interact with native code. They have to,
because eventully everything shown on the screen interacts with native
code. What matters is the peer that gets it there.
The distinction between heavyweights and lightweights, as far as AWT and
Swing are concerned, is whether the Component's peer is an instance of a
lighweight peer or not. Beyond that, there isn't much you can assume, and
for good reason: hiding implementation details.
There was no light/heavy distinction possible until JDK 1.1, when
LightweightPeer was added. But as of 1.1 and everything after, its the
peer's type that determines its "weight". See the source for
java.awt.Component, and the package java.awt.peer. Also see
Toolkit.createComponent() vs. the other Toolkit methods that create
type-specific "heavyweight" peers.
The way lightweight peers typically work is that a top-level container
(e.g. Window or Frame) provides a single drawing surface for all the
lightweight components it contains. Lightweights are "light" only because
they share a common native surface, and so can get away with using nothing
but pure Java code to render things on that surface (i.e. the top-level
ancestor's surface). Heavyweights are heavy because each peer of each
component is responsible for its own surface.
Lightweights often use only pure Java rendering, but they don't have to.
They could be implemented so that native code is called to draw on the
top-level container's shared surface. The Aqua PLAF does this, for example.
Conversely, "heavyweight" components, which have a type-specific peer, can
be implemented entirely in Java. That is, a ButtonPeer could be pure Java,
and draw on a simple blank surface. Implementations are left to
java.awt.Toolkit, which manufactures all peers.
Any Swing PLAF on any platform is free to use native code, if it so
chooses. It's entirely possible that a Windows PLAF can be implemented
using an approach like the Aqua PLAF, i.e. using native rendering code to
draw UI elements.
In short, Swing components are always lightweight, but that's because they
all have a lightweight peer (except top-level containers). Swing PLAFs may
or may not use native code: it's an implementation decision, that has
almost nothing to do with whether a component is lightweight or not.
Lightweight or heavyweight doesn't necessarily imply native or non-native,
nor vice versa.
To address the original poster's question:
> The
>justification for some of this is that Mac Java components are not
>implemented the same as Java on other platforms. This seems
>believable since Apple has their own JVM. But is it true?
In a literal sense, it's true. The Mac's Toolkit implementation is
Mac-specific.
In another sense, it shouldn't matter, because every Toolkit implementation
on every platform is platform-specific. Being Mac-specific is no different
than being Windows-specific or GTK-specific or any-platform-here-specific.
If you're assuming something about a Toolkit or its peers, or the default
PLAF, or anything like that, then you have platform-specific assumptions.
Whether you can eliminate the code resulting from such assumptions depends
on what the code is and what the assumption is.
>1) If an AWT component is heavyweight on Win XP, is it on the Mac also?
>
>2) Is there a third in-between weight-ness on Mac? This is what my
>cohorts say that prompted this e-mail. If true, what does this mean?
I don't think the answers to those questions are going to answer what you
really want to know:
Is the Mac-specific code necessary, or is it removable?
I think this because the heavyweight/lightweight distinction doesn't
necessarily imply anything about how something is implemented or rendered.
In particular, you cannot conclude that lightweight implies no native code.
Nor does native code imply heavyweight.
If you're hoping to remove Mac-specific code, we'd have to know exactly
what your code is and what it does and why it was actually written, in
order to determine whether it's necessary or not. The real answer may be
something in-between, such as the Mac-specific code is necessary under 1.3,
but not under 1.4 or 1.5. Stranger things have happened.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
