Review request: initial check-in for Cocoa-based AWT and lightweight peers

[Mike Swingler]

On Mar 31, 2011, at 7:43 AM, Artem Ananiev wrote:

> Hi, team,
> 
> as all you know, one of the major areas for contribution to MacOSX OpenJDK port is UI libraries: AWT, Java2D, Swing. Currently, macosx-port repository only contains X11-based implementation copied from BSD port, and it's time to start a new, Cocoa-based one.
> 
> Here is the webrev:
> 
> http://cr.openjdk.java.net/~art/macosx-port/lwawt-initial-checkin/

After reviewing this (since so much of the code is familiar to us already), this looks great.

To give everyone else some context, this change set is just part of several more which have been developed between Apple, Oracle, and previously Sun. We are already in the process of preping more changesets that are dependent on this basic Cocoa graphics infrastructure.

> It's huge, and I don't expect a comprehensive review right now. The easier way is to apply the patch and to try running some applications. To enable the new toolkit, you need to set AWT_TOOLKIT environment variable. Here is an example to run Notepad demo shipped with JDK:
> 
> AWT_TOOLKIT=CToolkit <BUILD>/java -jar demos/jfc/Notepad/Notepad.jar
> 
> By default, without AWT_TOOLKIT specified, X11 toolkit (which is sun.awt.X11.XToolkit) is used. Headless support is to come a bit later.

As an FYI, the default will change in the future, and we will have a mechanism that does not rely on an environment variable, but for immediate bringup, this is simply a hack to get Cocoa developers going that won't destabilize anyone else.

> The implementation is far from complete and robust. Many AWT components are missed: ScrollPane, TextArea and others. Many non-component classes like java.awt.Desktop or printing support are missed as well. There are some rendering artifacts on resize. All these are known limitations, and I'm going to file separate bugs for all the issues I notice and you report.

Bug reports go to: <http://java.net/jira/browse/MACOSX_PORT>

> Here is some high-level technical background:
> 
> 1. The webrev can be logically split into several parts: Makefile changes, fonts stuff, lightweight peers, MacOSX specific platform peers, OpenGL pipeline.
> 
> 2. As on Linux/Solaris platforms, AWT/2D is build into two different libraries: <JRE>/lib/libawt.dylib and <JRE>/lib/lwawt/liblwawt.dylib Whether to load xawt/libmawt or lwawt/liblwawt is decided in awt_LoadLibrary.c, that is, at the time when AWT is loaded with a call to System.loadLibrary("awt"), typically, from Toolkit.java
> 
> 3. Lightweight peers. This is the layer in sun.lwawt package to implement AWT regular components using Swing. I know it sounds really weird, but this is what I said :) The only heavyweight component is java.awt.Window and its counterpart sun.lwawt.LWWindowPeer. The peer forwards most of the calls to PlatformWindow, which is an interface, currently only implemented on MacOSX (but I don't see any obstacles to implement it on other platforms, if we find it useful later).

To also provide some context for this architectural decision - we (at least at Apple) consider the AWT widget peers to be effectively deprecated API. We wanted to ensure that the basic graphics infrastructure of the JDK7 AWT used OpenGL out of the box, so we decided that the old heavyweight components should be implemented in a way that will not prevent that.

At some point in the future, it may be necessary to elevate other AWT peers to become top-level OpenGL contexts (via overlay windows or CoreAnimation layers), but for right now, we are proceeding with simplest architecture. Ironically, this complicates the implementation of these legacy controls. I would like to thank the Sun and Oracle engineers who helped us with this significant undertaking.

> 4. The classes in sun.lwawt.macosx are platform-specific counterparts of lightweight peer. One of them, CPlatformWindow, is the implementation of PlatformWindow interface, others are for menus, cursors, robot and other stuff.
> 
> 5. At the native level, CPlatformWindow delegates the work to an instance of AWTWindow, which is a subclass of NSWindow. This class receives all the input and other events, dispatches them to CPlatformWindow, which forwards them to LWWindowPeer and then to a proper AWT component.

Artem, thanks much giving this the final scrub and polish for us to push this public,
Mike Swingler
Java Engineering
Apple Inc.