The Java Native Rendering library actually contains three renderers, with different implementations. These renderers differ in their limitations and their performance. The three renderers are combined into a hybrid renderer that selects a renderer from the available renderers for each rendering operation to produce the most accurate result with the best performance.
Native View Renderer
This renderer creates an image of a native UI control by actually creating a native control (some kind of NSView) and rendering it into an image. Note, however, that the control is not a live control. From the platform point of view, the control never appears on a screen and the code that supports the control’s behavior never runs.
This technique is not new. It is used by all of the major browsers to display checkboxes and other controls as if they were native controls. In actuality, the browser is simply displaying an image of a control and simulating its behavior in response to mouse clicks and other user gestures.
The current implementation of the native view renderer should be considered a proof of concept. Besides caching images, little has been done to optimize its performance. The hybrid renderer uses the native view renderer only where necessary to produce an accurate image or when the other renderers are not available.
Native Rendering Framework
This renderer uses the same native rendering framework used by most AppKit views. Where possible, the (supported and minimally documented) Java Runtime Support framework API is used to access the native rendering framework.
This renderer uses the same native rendering framework used by the previous renderer, but uses private JDK classes that provide an optimized, but restricted path to that framework. This renderer is the most efficient but also has many restrictions. This renderer may not work in future releases of the JDK where access to private JDK classes may be restricted.