At least on the Windows platform, the disposal of EmbeddedFrames (WEmbeddedFrames) is fragile and can lead to situations where the AppContext in which the WEmbeddedFrame was created can not be properly disposed.

If the holder of a WEmbeddedFrame destroys the containing window before WEmbeddedFrame.dispose() is called, the native peer will process the WM_DESTROY windows message and destroy and unlink the native peer from the Java-level WEmbeddedFrame object without giving it an indication that it has been destroyed. Subsequent calls to WEmbeddedFrame.dispose() will raise a NullPointerException. If an NPE is raised during AppContext.dispose() (the loop processing ownerless windows, at least in JDK 6 and later) then other top-level windows won't be properly disposed. The WEmbeddedFrame.dispose() code should be made more robust, as should the loop in AppContext.dispose(), since if any exception is raised during window disposal, other windows and resources won't be properly disposed. In the case of the Java Plug-In, this has the bad side-effect of potentially leaving applets' top-level windows on the screen after the applet has theoretically terminated.