Why Were Applets Deprecated in Jdk 9

Why were applets deprecated in JDK 9?

Applets were very popular a couple of years ago, but now the browser world changed and security is becoming a major focus for all major browser vendors.

The Java team gave its complete set or reasons, alternatives etc. in the document Migrating from Java Applets to plugin-free Java technologies. On page 4, there is the following Executive Overview:

With modern browser vendors working to restrict or reduce the support of plugins like Flash, Silverlight and Java in their products, developers of applications that rely on the Java browser plugin need to consider alternative options. Java developers currently relying on browser plugins should consider migrating from Java Applets to the plugin-free Java Web Start technology.
Supporting Java in browsers is only possible for as long as browser vendors are committed to supporting standards based plugins. By late 2015, many browser vendors had either removed or announced timelines for the removal of standards based plugin support, while some are introducing proprietary browser-specific extension APIs. Consequently, Oracle is planning to deprecate the Java browser plugin in JDK 9.
The deprecated plugin technology will be completely removed from the Oracle Java Development Kit (JDK) and Java Runtime Environment (JRE) in a future Java release TBD. Java Web Start applications do not rely on a browser plugin and will not be affected by these changes.

Are applets now deprecated?

Applets (as applications written in Java and intended to run inside a browser) are not deprecated in any way in HTML specifications or drafts. There is decreasing interest in them, due to many other alternatives being available, but that’s a different issue.

The applet element was declared deprecated in HTML 4, in favor of the object element. In HTML 4, deprecation means that element is still part of the language, browsers are recommended to support it (though in practice, not all browsers support it, and some browsers could not support it), but there is a recommendation to use something else (in this case, object) instead of it.

In HTML5 CR, the word “deprecated” is not used. It uses the term “obsolete”, which means in principle something quite different but comes very close in practice. In HTML5 CR, the applet element is declared “entirely obsolete and non-conforming”, with the note that it “must not be used by authors”. Yet, HTML5 contains a definition of applet under “Requirements for implementations”. And HTML5 conformance requirements specify that normal browsers must (not just should) support it.

One of the few real differences between the HTML 4 concept “deprecated” and the HTML5 concept “obsolete” is in validation: when validating against an HTML 4 DTD, applet is accepted when the Transitional DTD is used (but flagged as an error when validating against the Strict DTD); in HTML5 validation, applet is reported as an error.

P.S. W3schools should not be used as any kind of authority or reference, see http://w3fools.com

UPDATE 2021 - Applets were officially deprecated by Oracle in Java 9. So while W3Schools were not strictly correct at the time that this article was written, what they said then is correct ... now.

The main reason that Oracle gave for deprecating Applets was that most modern web browsers have stopped supporting them. As of right now, (AFAIK) only Internet Explorer still supports Applets, and IE is due to go EOL in mid 2022.

Applet not running

As Java Client Roadmap Update

During the past five years, most browser vendors have withdrawn
support for plugins such as Flash, Silverlight, and Java in their
products. Supporting Java Applets in browsers was only possible as
long as browser vendors were committed to supporting standards based
plugins. By late 2015, many browser vendors had either removed or
announced timelines for the removal of standards-based plugin support,
while some introduced proprietary browser-specific extension APIs.
Consequently:
Existing Applet support in Java SE 8 will continue through March 2019, after which it may be removed at any time.
Oracle announced in January 2016 that Applets would be deprecated in Java SE 9, and removed from Java SE 11 (18.9).

If you have Java 8 or prior installed with necessary files. You can try appletviewer

Java Web Start support in Java 9 and beyond

According to http://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html

Java Deployment Technologies are deprecated and will be removed in a future release
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.

There is a related discussion on the OpenJDK discuss list here: http://mail.openjdk.java.net/pipermail/discuss/2017-November/004586.html

Oracle will not include Java Web Start in Java SE 11 (18.9 LTS) and later.

Source: Java Client Roadmap Update 2018-03-05 (Oracle)

is java 9 and above still platform independent or not after this module system has been introduced?

You are conflating two different changes recently made to the Java platform:

Retiring of Java Web Start & Applet technologies
Modularization

Retiring desktop-technologies

Recently Oracle announced the phasing out of the Java Web Start technologies, in addition to the already-deprecated Applet technology. See item JDK-8184998 in Java 9 Release Notes:

Java Deployment Technologies are deprecated and will be removed in a future release
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.

End-users will no longer be encouraged to install a JDK or JRE on their computer.

For more details, see the eight-page 2018-03 white paper from Oracle, Java Client Roadmap Update.

So then, how are developers of Swing or JavaFX apps to deliver their software to the end-user?

Oracle suggests packaging up your app along with a JVM & JRE for delivery as a single launch-ready applications on that appears on the client to be just another app alongside the native apps. Such “double-clickable” app-packaging has been commonly done on the Mac since the beginning of Java. But what was once an obscure art on other host environments (Linux, BSD, Windows, etc.) will now be the norm, as it is on macOS.

In yesteryear, bundling a Java runtime with your app required jumping over some licensing hurdles. The legalities have eased with arrival of the open-source OpenJDK project, and possibly with other implementations^†.

You will need to prepare different releases of your app for each hosting environment. While your Java code runs independently of the host OS, the JVM is built of native code to interact with one specific kind of host. So you will need to build a Linux release with a Linux JVM, a macOS release with a macOS JVM, and so on. While that may seem like a downer, the upside is that you no longer need to worry about users having the wrong JVM version installed, or no JVM at all. Now the JVM’s presence and version are under your control. Your end-users and customers will no longer need to be aware that your app is Java-based.

Modularization

That need for app-packaging has nothing to do with the modularization of Java. As I said, it has been done for decades on the Mac.

What modularization brings to the party is that the JVM/JRE you bundle into your delivered app can be customized to contain only the Java Modules actually utilized by your particular app. This results in a smaller size, so your finished app is smaller, downloads are faster, less storage is used, and your app may load faster.

The open-source jlink “Java Linker” tool helps with the packaging work, so you can assemble and optimize a set of modules and their dependencies (only the ones actually called by your app) into a custom run-time image. This modular run-time image format is defined in JEP 220.

^† On a related note, you may want to read the white paper Java Is Still Free to understand how and where to obtain a Java implementation for your app, and what support may or may not be offered in either free-of-cost or paid releases.

By the way, you may find helpful this Answer on a related Question, with a flowchart of choosing various sources of a Java implementation.

What happens in this code snippet with the Applet class?

Applets are an old, deprecated technology and you should consider newer technologies such as Java Web Start. That said, your understanding is mostly correct apart from some of the terminology.

I create a class of name aClass that inherit(because it becomes a daughter) methods and attributes of the Applet class;

Extending a class means that you create a new sub-class (in this case aClass) which is based off of the public contract and private implementation of the super class (Applet). The way that aClass behaves should respect the Liskov substitution principle at a high level meaning that anywhere you can use an Applet, you should be able to use an aClass too. This means respecting the public contract of Applet in aClass.

Applet class; then overwrites the paint method(which had been inherited from Applet),

Partially correct. aClass will override paint meaning that it will called when invoking paint on an instance of aClass rather than the default definition in Applet. It does not overwrite, as it is still possible to call the super implementation of this method. You should also annotate overriden method with the @Override annotation

@Override
public void paint(Graphics g){
    // calls paint from higher up the inheritance tree
    super.paint(g); 
    g.drawRect(0, 0, 400, 200);
}

this method expects an object as a parameter (which we put name g) created from the class Graphics,

Yes, or just like aClass extends Applet, this could be some class that also extends Graphics.

e.g. class FooGraphics extends Graphics { ... }

and then we call the drawRect method that is proper to the g object (which was created from the Graphics class);

Yup. Part of the public contract to the Graphics class.

so that when the aClase class is executed, a rectangle is drawn, is it like that?

Whenever the Applet framework decides to update the view it will call this method which has the effect of drawing a rectangle.

Migrating to Java Web Start - Will Applet-Desc be deprecated?

The thing that is deprecated is done by the browser manufacturers (though Oracle, realising the situation now advises not to develop them). So Oracle has not 'deprecated' the applet tag(1) in the same way that it has deprecated other classes, methods or attributes as occasionally mentioned in the Java Docs.

As to launching the applet using JWS, yes that should still 'work'. But note that whereas (for example) Chrome used to pass a JNLP direct to the program registered as a consumer of that file type (wherein it would be passed to the Java Web Start Client included in the JRE), it now causes the user to first download the JNLP, then explicitly choose to launch that file.

Update: Oracle may not have deprecated the applet tag, but they'll do effectively the same thing come Java 9. From JDK 9 and the Java Plugin:

By late 2015, many browser vendors have either removed or announced timelines for the removal of standards based plugin support, eliminating the ability to embed Silverlight, Java, Flash and other standards-based plugin technologies.
Oracle plans to deprecate the Java browser plugin in Java Standard Edition Development Kit 9 (JDK 9). Deprecation is a warning for developers to stop using this technology. JRE 9 will continue to provide the Java Plugin and support launching applets on browsers that still offer standard plugin support. This browser plugin will be removed from the Oracle JDK and JRE in a future Java SE release. Developers and users who want to learn more about this planned change can find out more in this blog post.

Why Were Applets Deprecated in Jdk 9