Summary

Remove the entire java.applet.Applet API, including classes and methods which depend on it.

Problem

The Applet API was designed for untrusted, downloaded code, typically running in a web browser. Web browsers no longer allow the JVM to be embedded, and the Java Security Manager which was necessary to sandbox the untrusted code is permanently disabled. There is also no implementation in the JDK which can be used to run applets, even in a local trusted environment.

Solution

Remove all classes in the java.applet package, and the package itself, thereby removing the entire Applet API. Also remove any classes or methods which depend on the removed Applet API. Also update all javadoc which references applets or the Applet API.

Specification

This is divided into 3 principal sections

• class / interface removals
• method removals
• javadoc text updates.

NB, as a consequence javax.swing.RepaintManager appears in two sections due to a method removal and a separate doc update

CLASS / INTERFACE removals

Remove all classes (listed below) in the java.applet package, including removing java.applet.package-info

java.applet.Applet
java.applet.AppletContext
java.applet.AppletStub
java.applet.AudioClip

Remove the class javax.swing.JApplet

Remove the interface java.beans.AppletInitizalizer

METHOD removals :

class java.beans.Beans :
Remove the method which uses AppletInitializer
-    /**
-     * Instantiate a bean.
-     *
-     * The bean is created based on a name relative to a class-loader.
-     * This name should be a dot-separated name such as "a.b.c".
-     *
-     * In Beans 1.0 the given name can indicate either a serialized object
-     * or a class.  Other mechanisms may be added in the future.  In
-     * beans 1.0 we first try to treat the beanName as a serialized object
-     * name then as a class name.
-     *
-     * When using the beanName as a serialized object name we convert the
-     * given beanName to a resource pathname and add a trailing ".ser" suffix.
-     * We then try to load a serialized object from that resource.
-     *
-     * For example, given a beanName of "x.y", Beans.instantiate would first
-     * try to read a serialized object from the resource "x/y.ser" and if
-     * that failed it would try to load the class "x.y" and create an
-     * instance of that class.
-     *
-     * If the bean is a subtype of java.applet.Applet, then it is given
-     * some special initialization.  First, it is supplied with a default
-     * AppletStub and AppletContext.  Second, if it was instantiated from
-     * a classname the applet's "init" method is called.  (If the bean was
-     * deserialized this step is skipped.)
-     *
-     * Note that for beans which are applets, it is the caller's responsibility
-     * to call "start" on the applet.  For correct behaviour, this should be done
-     * after the applet has been added into a visible AWT container.
-     *
-     * Note that applets created via beans.instantiate run in a slightly
-     * different environment than applets running inside browsers.  In
-     * particular, bean applets have no access to "parameters", so they may
-     * wish to provide property get/set methods to set parameter values.  We
-     * advise bean-applet developers to test their bean-applets against both
-     * the JDK appletviewer (for a reference browser environment) and the
-     * BDK BeanBox (for a reference bean container).
-     *
-     * @return a JavaBean
-     * @param     cls         the class-loader from which we should create
-     *                        the bean.  If this is null, then the system
-     *                        class-loader is used.
-     * @param     beanName    the name of the bean within the class-loader.
-     *                        For example "sun.beanbox.foobah"
-     * @param     beanContext The BeanContext in which to nest the new bean
-     * @param     initializer The AppletInitializer for the new bean
-     *
-     * @throws ClassNotFoundException if the class of a serialized
-     *              object could not be found.
-     * @throws IOException if an I/O error occurs.
-     * @since 1.2
-     *
-     * @deprecated It is recommended to use
-     * {@link #instantiate(ClassLoader, String, BeanContext)},
-     * because the Applet API is deprecated. See the
-     *  java.applet package
-     * documentation for further information.
-     */
-    @Deprecated(since = "9", forRemoval = true)
-    @SuppressWarnings("removal")
-    public static Object instantiate(ClassLoader cls, String beanName,
-                                     BeanContext beanContext,
-                                     AppletInitializer initializer)
-            throws IOException, ClassNotFoundException

class javax.swing.RepaintManager : 

Remove the addDirtyRegion method which accepts an applet :-
-    /**
-     * Adds applet to the list of Components that
-     * need to be repainted.
-     *
-     * @param applet Applet to repaint, null results in nothing happening.
-     * @param x X coordinate of the region to repaint
-     * @param y Y coordinate of the region to repaint
-     * @param w Width of the region to repaint
-     * @param h Height of the region to repaint
-     * @see JApplet#repaint
-     * @since 1.6
-     *
-     * @deprecated The Applet API is deprecated. See the
-     *  java.applet package
-     * documentation for further information.
-     */
-    @Deprecated(since = "9", forRemoval = true)
-    @SuppressWarnings("removal")
-    public void addDirtyRegion(Applet applet, int x, int y, int w, int h);

JAVADOC TEXT UPDATES :

Update javadoc in various classes which discuss the handling etc of Applets.

interface java.beans.DesignMode : update class javadoc as follows :
 * The JavaBeans specification defines the notion of design time as is a
  * mode in which JavaBeans instances should function during their composition
  * and customization in a interactive design, composition or construction tool,
- * as opposed to runtime when the JavaBean is part of an applet, application,
+ * as opposed to runtime when the JavaBean is part of an application,
  * or other live Java executable abstraction.

class javax.imageio.spi.IIORegistry :
-     * 
 Each {@code ThreadGroup} will receive its own
-     * instance; this allows different {@code Applet}s in the
-     * same browser (for example) to each have their own registry.
+     * 
 Each {@code ThreadGroup} will receive its own instance.
public static IIORegistry getDefaultInstance()


class java.awt.Component.FlipBufferStrategy :

         /**
          * Creates a new flipping buffer strategy for this component.
-         * The component must be a {@code Canvas} or {@code Window} or
-         * {@code Applet}.
+         * The component must be a {@code Canvas} or {@code Window}.
         protected FlipBufferStrategy(int numBuffers, BufferCapabilities caps)
             throws AWTException;

class java.awt.Container :

-     * The {@code Window} class and the {@code Applet} class are the validate
-     * roots in AWT.  Swing introduces more validate roots.
+     * The {@code Window} class is the validate root in AWT.
+     * Swing introduces more validate roots.
 public boolean isValidateRoot();

class java.awt.Dialog :

         /**
          * An {@code APPLICATION_MODAL} dialog blocks all top-level windows
          * from the same Java application except those from its own child hierarchy.
-         * If there are several applets launched in a browser, they can be
-         * treated either as separate applications or a single one. This behavior
-         * is implementation-dependent.
          */
         APPLICATION_MODAL,
         /**
          * A {@code TOOLKIT_MODAL} dialog blocks all top-level windows run
-         * from the same toolkit except those from its own child hierarchy. If there
-         * are several applets launched in a browser, all of them run with the same
-         * toolkit; thus, a toolkit-modal dialog displayed by an applet may affect
-         * other applets and all windows of the browser instance which embeds the
-         * Java runtime environment for this toolkit.
+         * from the same toolkit except those from its own child hierarchy.
          */
         TOOLKIT_MODAL

class java.awt.EventQueue : Update class javadoc to remove the following text :
- * Some browsers partition applets in different code bases into
- * separate contexts, and establish walls between these contexts.
- * In such a scenario, there will be one {@code EventQueue}
- * per context. Other browsers place all applets into the same
- * context, implying that there will be only a single, global
- * {@code EventQueue} for all applets. This behavior is
- * implementation-dependent.  Consult your browser's documentation
- * for more information.
- * 


class java.awt.Frame :
     /**
      * Returns an array of all {@code Frame}s created by this application.
-     * If called from an applet, the array includes only the {@code Frame}s
-     * accessible by that applet.
public static Frame[] getFrames();

class java.awt.GraphicsEnvironment :
      * After calling this method for such a font, it is available to
      * be used in constructing new {@code Font}s by name or family name,
      * and is enumerated by {@link #getAvailableFontFamilyNames} and
      * {@link #getAllFonts} within the execution context of this
-     * application or applet. This means applets cannot register fonts in
-     * a way that they are visible to other applets.
+     * application.
public boolean registerFont(Font font);

class java.awt.KeyboardFocusManager :
      *    
whether the KeyboardFocusManager is currently managing focus
-     *        for this application or applet's browser context
+     *        for this application
public void addPropertyChangeListener(PropertyChangeListener listener) 

      *    
whether the KeyboardFocusManager is currently managing focus
-     *        for this application or applet's browser context
+     *        for this application
public void addPropertyChangeListener(String propertyName, PropertyChangeListener listener)

class java.awt.SystemTray :
     /**
      * Returns an array of all icons added to the tray by this
      * application.  You can't access the icons added by another
-     * application.  Some browsers partition applets in different
-     * code bases into separate contexts, and establish walls between
-     * these contexts.  In such a scenario, only the tray icons added
-     * from this context will be returned.
+     * application.
public TrayIcon[] getTrayIcons();


class java.awt.Toolkit :

     /**
-     * Get the application's or applet's EventQueue instance.
-     * Depending on the Toolkit implementation, different EventQueues
-     * may be returned for different applets.  Applets should
-     * therefore not assume that the EventQueue instance returned
-     * by this method will be shared by other applets or the system.
-     *
-     * @return    the {@code EventQueue} object
+     * {@return the {@code EventQueue} for this application}
     */
     public final EventQueue getSystemEventQueue();

     /**
-     * Gets the application's or applet's {@code EventQueue}
-     * instance, without checking access.  For security reasons,
-     * this can only be called from a {@code Toolkit} subclass.
+     * A method used by toolkit subclasses to get the {@code EventQueue}.
+     * This may be more direct or more efficient than calling
+     * {@code getSystemEventQueue()}.
      * @return the {@code EventQueue} object
      */
     protected abstract EventQueue getSystemEventQueueImpl();


class java.awt.Window :
     /**
      * Returns an array of all {@code Window}s, both owned and ownerless,
      * created by this application.
-     * If called from an applet, the array includes only the {@code Window}s
-     * accessible by that applet.
public static Window[] getWindows() ;

     /**
      * Returns an array of all {@code Window}s created by this application
      * that have no owner. They include {@code Frame}s and ownerless
      * {@code Dialog}s and {@code Window}s.
-     * If called from an applet, the array includes only the {@code Window}s
-     * accessible by that applet.
public static Window[] getOwnerlessWindows();


Update the package documentation for javax.swing as follows :-
  * Where the impact lies, however, is in constructing and showing a Swing
- * application. Calls to an application's {@code main} method, or methods in
- * {@code Applet}, are not invoked on the event dispatching thread. As such,
+ * application. Calls to an application's {@code main} method,
+ * are not invoked on the event dispatching thread. As such,
  * care must be taken to transfer control to the event dispatching thread when
- * constructing and showing an application or applet. The preferred way to
+ * constructing and showing an application. The preferred way to
  * transfer control and begin working with Swing is to use {@code invokeLater}.


class javax.swing.JComponent : Update class javadoc as follows
  * The base class for all Swing components except top-level containers.
  * To use a component that inherits from JComponent,
  * you must place the component in a containment hierarchy
  * whose root is a top-level Swing container.
  * Top-level Swing containers --
- * such as JFrame, JDialog,
- * and JApplet --
+ * such as JFrame, JDialog --

     /**
      * Returns the default locale used to initialize each JComponent's
      * locale property upon creation.
      *
-     * The default locale has "AppContext" scope so that applets (and
-     * potentially multiple lightweight applications running in a single VM)
-     * can have their own setting. An applet can safely alter its default
-     * locale because it will have no affect on other applets (or the browser).
-     *
public static void setDefaultLocale( Locale l);


class javax.swing.JRootPane : Update class javadoc as follows
 /**
  * A lightweight container used behind the scenes by
  * JFrame, JDialog, JWindow,
- * JApplet, and JInternalFrame.
+ * and JInternalFrame.
....
....

  * The following image shows the relationships between
  * the classes that use root panes.
- * 

+ * HEIGHT=600 WIDTH=850>

  * The "heavyweight" components (those that delegate to a peer, or native
- * component on the host system) are shown with a darker, heavier box. The four
- * heavyweight JFC/Swing containers (JFrame, JDialog,
- * JWindow, and JApplet) are
- * shown in relation to the AWT classes they extend.
- * These four components are the
- * only heavyweight containers in the Swing library. The lightweight container
- * JInternalFrame is also shown.
- * All five of these JFC/Swing containers implement the
- * RootPaneContainer interface,
- * and they all delegate their operations to a
- * JRootPane (shown with a little "handle" on top).
+ * component on the host system) are shown with a heavier box. AWT components in red,
+ * Swing heavyweights in blue.
+ * The three heavyweight JFC/Swing containers ({@code JFrame}, {@code JDialog}, and
+ * {@code JWindow}) are shown in relation to the AWT classes they extend.
+ * These three components are the only heavyweight containers in the Swing library.
+ * The lightweight container {@code JInternalFrame} is also shown in green with thin outline.
+ * All four of these JFC/Swing containers implement the {@code RootPaneContainer} interface,
+ * and they all delegate their operations to a {@code JRootPane}.


class javax.swing.JViewport :
      * To avoid excessive validation when the containment hierarchy is
      * being created this will not validate if one of the ancestors does not
      * have a peer, or there is no validate root ancestor, or one of the
-     * ancestors is not a Window or Applet.
+     * ancestors is not a Window.
public void scrollRectToVisible(Rectangle contentRect);

class javax.swing.RepaintManager : update class javadoc as follows :
  * As of 1.6 RepaintManager handles repaint requests
- * for Swing's top level components (JApplet,
- * JWindow, JFrame and JDialog).
+ * for Swing's top level components
+ * (JWindow, JFrame and JDialog).


interface javax.swing.RootPaneContainer : update class javadoc as follows :
/**
  * This interface is implemented by components that have a single
- * JRootPane child: JDialog, JFrame, JWindow, JApplet, JInternalFrame.
+ * JRootPane child: JDialog, JFrame, JWindow, JInternalFrame.
...
...
  * As a convenience, the standard classes that implement this interface
- * (such as {@code JFrame}, {@code JDialog}, {@code JWindow}, {@code JApplet},
+ * (such as {@code JFrame}, {@code JDialog}, {@code JWindow},
  * and {@code JInternalFrame}) have their {@code add}, {@code remove},
  * and {@code setLayout} methods overridden, so that they delegate calls
  * to the corresponding methods of the {@code ContentPane}.
...
...
  * The behavior of the add and
  * setLayout methods for
  * JFrame, JDialog, JWindow,
- * JApplet and JInternalFrame is controlled by
+ * and JInternalFrame is controlled by
  * the rootPaneCheckingEnabled property.


class javax.swing.SwingUtilities :
     /**
      * Returns the root component for the current component tree.
      *
      * @param c the component
-     * @return the first ancestor of c that's a Window or the last Applet ancestor
+     * @return the first ancestor of c that's a Window
      */
     @SuppressWarnings("removal")
     public static Component getRoot(Component c)

The following two documents are referenced from the java.awt package documentation

Remove references to applets from 'The AWT Focus Subsystem specification': src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html

-KeyboardFocusManager and Browser Contexts
-

-Some browsers partition applets in different code bases into separate
-contexts, and establish walls between these contexts. Each thread and
-each Component is associated with a particular context and cannot
-interfere with threads or access Components in other contexts. In such
-a scenario, there will be one KeyboardFocusManager per context. Other
-browsers place all applets into the same context, implying that there
-will be only a single, global KeyboardFocusManager for all
-applets. This behavior is implementation-dependent. Consult your
-browser's documentation for more information. No matter how many
-contexts there may be, however, there can never be more than one focus
-owner, focused Window, or active Window, per ClassLoader.

Remove references to applets from "The AWT Modality" documentation src/java.desktop/share/classes/java/awt/doc-files/Modality.html

       
Application-modal dialogs

         An application-modal dialog blocks all windows from the same
         application except for those from its child hierarchy.
-        If there are several applets launched in a browser, they can be
-        treated either as separate applications or a single application.
-   This behavior is implementation-dependent.
       
Toolkit-modal dialogs

         A toolkit-modal dialog blocks all windows that run in the same
-        toolkit except those from its child hierarchy. If there
-        are several applets launched all of them run with the same toolkit,
-        so a toolkit-modal dialog shown from an applet may affect other
-        applets and all windows of the browser instance which embeds the
-        Java runtime environment for this toolkit.
+        toolkit except those from its child hierarchy.

       The default modality type is application-modal. It is used by the API
       calls: Dialog.setModal(true),
       Dialog(owner, true), etc. Prior to JDK 6
       the default type was toolkit-modal,
-      but the only distinction between application- and toolkit-modality is for
-      applets and applications launched from Java Web Start.
+      and now with single application per-VM there is no
+      distinction between application- and toolkit-modality