The new native drawing support in the Kestrel (1.3) release
is a welcome addition and will likely see use in the market.

This feature works as advertised, however there is an
area of difficulty that the programmer has in coding
the native side of the component.  The problem has to do with
management of allocation of various native resources.  The
AWT implementation already has methods in its native implementation
to manage these resources, but access to those methods is not
available to one programming to the JAWT interface.  This means,
then, that the programmer must separately manage allocation of 
those same resources.

The project proposal is to extend the native JAWT structures to
have additional methods.  The extension must be on a per platform
basis since both the specific resources to coordinate, and the
data types to use, are unique to each platform.

N/A

Will look at this for Merlin. 
  xxxxx@xxxxx   1999-11-01

Other important notes, from licensee feedback:

We should allow access to the window handle of a window as well as a Canvas. This would be
especially useful for people using the EmbeddedWindow to embed a Java window in a C/C++ application.

  xxxxx@xxxxx   2000-03-29

I am rolling the details of 4272672, a slightly older RFE, into this more general one, and closing that one out as a duplicate.   Details are below:


It would be very helpful to be able to lock the AWT monitor
as per the lock() method in the DrawingSurfaceInfo classes
outwith the scope of a drawing surface.

On X11 platforms, any operations that might occur using the
X protocol but not via a drawing surface can result in 
breakdowns in the X11 protocol ( async reply problems )
which will terminally hang the application. This is bad.

The new native AWT API also suffers from this omission and
cannot be robustly used in all cases.

The SGI JDK-1.1.6 release featured two native methods called
awt_lock_enter() and awt_lock_exit() which basically locked
the AWT monitor ensuring that no AWT calls were issued when
you might be doing something with X. Something similar as a
standard with the JDK and accessible via the JNI would be
fabulous.

  xxxxx@xxxxx   2000-04-26