|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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: This email sent to email@hidden
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.