The Pixels class was designed to not keep a reference to a native object (such as an HBITMAP on Windows, NSImage on Mac, or e.g. XImage on X11).

The code that wants to access the content of a Pixels object (e.g. View.uploadPixels(), Window.setIcon(), etc.) passes a Java reference to the Pixels object to native code. The native code then creates a native image object (such as HBITMAP, NSImage, etc.) and calls the Pixels.attachData() passing it a pointer to this native image object in order to fill in the content of the image from the Java array stored in the Pixels. After using this native object, it must be removed right in the code that created it (e.g. right in the View.uploadPixels() implementation). This avoids keeping a pointer to the native object in Java code, and also avoids the need to dispose it some time later.

For an example, see the implementation on MS Windows. There's a Pixels C++ class which encapsulates handling of Glass Pixels objects in native code on Windows.

The current implementation of X11Pixels and LensPixels doesn't follow the design of the base shared Pixels class. Not only is this a wrong implementation by itself, but it also relies on the Glass Disposer machinery. The disposers must be removed from Glass in order to eliminate unused classes and thus boost the overall performance of Java FX. See RT-19477.