Software Developer differentiate a Java Applet from a Java Application

A software developer differentiates a Java Applet from a Java Application based on several key factors, including their purpose, execution environment, and lifecycle. Below is a detailed comparison of the two:

1. Execution Environment:
   • Java Applet:
     • Applets run inside a web browser or an applet viewer. They are designed to be embedded in HTML pages and executed in the context of a web page.
     • Applets require a Java plugin or support for Java in the browser, which has become obsolete in modern web environments. They are typically executed in a sandboxed environment for security reasons.
     • Example: A small program running on a website to create interactive web content, like animations or simple games.
   • Java Application:
     • A Java application is a standalone program that runs on a local machine's Java Virtual Machine (JVM). It does not depend on a web browser and is executed independently, typically through the command line or as a desktop application.
     • Example: A desktop utility application like a text editor or a banking system.
2. Purpose and Use Case:
   • Java Applet:
     • Applets were intended for use on the web to enhance user interaction in browsers (e.g., for animations, interactive charts, or lightweight games).
     • However, due to security risks and limited browser support, applets are now considered outdated and rarely used.
   • Java Application: Java applications are used for a wide range of purposes, including desktop applications, enterprise software, mobile apps (via Android), and server-side applications. Java applications are more versatile and robust compared to applets.
3. Entry Point (Main Method):
   • Java Applet:
     • Applets do not have a `main()` method. Instead, they use a predefined lifecycle with methods like `init()`, `start()`, `stop()`, and `destroy()`.
     • These lifecycle methods control the initialization, execution, and termination of the applet when embedded in a web page.
   • Java Application: A standard Java application must include a `main()` method, which serves as the entry point for execution.
     Example:
     

     public class MyApplication {
       public static void main(String[] args) {
     	  System.out.println("This is a Java application.");
       }
     }
     

4. Lifecycle Management
   • Java Applet:
     • The browser or applet viewer manages the applet's lifecycle. The browser calls `init()`, `start()`, `stop()`, and `destroy()` methods.
     • These methods handle the applet’s creation, starting, stopping, and cleanup when the user interacts with the web page.
   • Java Application: Java applications are managed directly by the JVM and the operating system. Once the `main()` method is executed, the application runs until the program terminates (either by completion or explicitly using `System.exit()`).
5. Security Model:
   • Java Applet:
     • Applets run in a restricted security sandbox to protect users from malicious code. This limits the applet's ability to perform file I/O, network communication, and other sensitive operations unless the applet is signed with a security certificate.
     • For unsigned applets, operations like reading or writing files on the local machine are prohibited.
   • Java Application: Java applications are not as restricted as applets. They can access system resources such as the file system, network, and external devices based on the permissions granted by the operating system and security policies.
6. User Interface (UI):
   • Java Applet:
     • Applets typically use AWT (Abstract Window Toolkit) or Swing components to build graphical user interfaces, which are embedded in a web page.
     • Since applets are meant for web interaction, their user interface is limited in functionality compared to desktop applications.
   • Java Application:
     • Java applications can also use AWT, Swing, or the more modern JavaFX to build comprehensive desktop GUIs with advanced functionality.
     • They have full access to the windowing system and user input devices like the keyboard and mouse.
7. Deployment:
   • Java Applet Applets are deployed by embedding them into HTML pages using the <applet> tag (now deprecated) or <object> / <embed> tags. The applet's `.class` file is stored on a web server and downloaded when a user accesses the web page.
     Example:
     

     <applet code="MyApplet.class" width="300" height="300">
     </applet>
     

   • Java Application: Java applications are deployed as `.jar` (Java Archive) files or distributed as part of a larger application package. They can be executed directly on the JVM using the command:
     

     java -jar MyApplication.jar
     

   
   
8. Obsolescence:
   • Java Applet: Java applets are deprecated and no longer supported by most modern browsers due to security vulnerabilities and the advent of more secure technologies like HTML5, JavaScript, and WebAssembly.
   • Java Application: Java applications remain a mainstream choice for a wide variety of software development projects, from desktop software to large-scale enterprise systems and mobile applications (via Android).

Summary Table

Feature	Java Applet	Java Application
Execution Environment	Runs in a web browser or applet viewer	Runs on a standalone JVM
Entry Point	No main() method; uses init(), start(), stop(), destroy()	Has a main() method
Lifecycle	Managed by the browser	Managed by the JVM
Security	Runs in a restricted security sandbox	Less restricted, depends on system permissions
UI Framework	AWT or Swing (limited to web pages)	AWT, Swing, JavaFX
Deployment	Embedded in HTML pages	Packaged as .jar or .class files
Use Case	Web-based interaction (now outdated)	Desktop apps, enterprise systems, mobile apps
Obsolescence	Deprecated and rarely used	Still widely used

In conclusion, Java Applets were once popular for enhancing web pages with Java-based interactivity, but they have largely been replaced by more secure and modern technologies. Java Applications, on the other hand, are versatile and remain central to many software development projects today.

Java programs are broken down into two fundamental types:

1. applets and
2. applications.

As you may already know, applets are graphical programs that were used during the dotcom era. They are rarely used today and have been replaced by the JavaFX API.
Question: How has the JavaFx API replaced the Java Applets which were heavily used from 1996 to 2000?
The JavaFX API is a set of Java libraries and tools for building rich, graphical user interfaces (GUIs) and multimedia applications. While it can be used to build applets, JavaFX is not intended as a direct replacement for Java Applets. Java Applets were heavily used in the late 1990s and early 2000s as a way to provide interactive features on websites. However, their usage declined in the following years due to security concerns and the increasing popularity of other technologies, such as JavaScript and Flash. JavaFX was introduced in 2008 as a modern replacement for Java Applets, but with a focus on building rich desktop and mobile applications, rather than web-based applets. JavaFX provides a range of features for building modern, responsive applications with advanced graphics and multimedia capabilities.
While JavaFX can be used to build web-based applications, it is not typically used as a direct replacement for Java Applets on websites. Instead, JavaFX is more commonly used to build standalone desktop and mobile applications, as well as embedded systems and other types of software that require rich graphical interfaces and multimedia capabilities. In summary, while JavaFX can be used to build applets, it is not intended as a direct replacement for Java Applets on websites. Instead, JavaFX is a modern API for building rich desktop and mobile applications with advanced graphical and multimedia capabilities. Java applications are different from applets because they can be graphical or command-line. Applications do not require a Web browser and run entirely on their own. Command-line Java applications are ideal for creating simple utilities due to their minimal overhead. Graphical Java applications typically are larger in scope.
Graphical Java applications are like applets in many ways except for the fact that they are responsible for creating and managing their own frame window (a Web page serves as the frame window for an applet). Java applications (like Java applets) are created as classes but are executed using the Java interpreter^[1] instead of a Web browser or the AppletViewer^[2].

1. Naming convention: All Swing component names begin with a capital J and follow the format JXxx. E.g., JFrame, JPanel, JApplet, JDialog, JButton. Many are just AWT names with a J.
2. Lightweight components: Most Swing components are lightweight: formed by drawing in the underlying window.
3. Use of paintComponent for drawing: Custom drawing code is in paintComponent, not paint. Double buffering turned on by default.
4. New Look and Feel as default: With Swing, you have to explicitly set the native look.
5. Don't mix Swing and AWT in same window

The following module discusses Applet and Servlet Interaction Applet and Servlet Interaction

• Graphical Applications: Graphical applications are useful when you want to create a program with a graphical user interface that does not reside on the Web. For example, you might want to write a graphical application to inventory your personal CD collection. In this case, it would not necessarily need to have any connection to a Web page. You will probably create command-line Java applications to serve as simple utilities. These simple utilities perform tasks such as processing files or getting system information, because their overhead is so minimal. Additionally, command-line Java applications can be very useful for testing code that you do not want to place in an applet. Suppose you have developed a sorting subroutine that sorts alphabetic names and you want to test it. This is not the kind of subroutine that would benefit from being placed in a graphical application when all you care about seeing are the names displayed in order.

Security plays the biggest role in distinguishing applets and applications. Applets are Web-based, which means that they could potentially cause lots of trouble on a computer with little warning. For this reason, they have Applets with Security.
Applications are manually installed by the user and are therefore considered secure by default, which means that they have little or no security limitations. The differing levels of security between applets and applications frequently result in limitations on what applets can functionally accomplish. As an example, you could develop an application that searched the local hard drive for information, while an applet could not accomplish this task under normal circumstances due to its security limitations.

• Applets with Security Clearance
  There are some situations where you want an applet to perform tasks outside of the normal security limitations. Fortunately, there is a way to declare an applet as being safe so that it can use certain "secure" features. Even so, users are still given a chance to verify secure applets before they are allowed to run. Applets attain a secure status by having a digital signature attached to them, which acts somewhat like a handwritten signature. A digital signature verifies the source of an applet and gives the user confidence that it has not been tampered with. The logic is that if you trust the applet source and deem it reliable, then you can trust the applet. Applets with digital signatures are referred to as signed applets, and have little or no security constraints.

Java applets are often subject to security restrictions that prevent them from performing tasks outside of their normal operating environment. However, there are ways to grant applets permission to access resources and perform tasks that would otherwise be prohibited. One way to do this is through the use of digital signatures. When an applet is signed with a digital signature, it is granted permission to access certain resources and perform specific tasks. This signature verifies the identity of the applet's creator and ensures that the applet has not been tampered with since it was signed.
Another way to grant applets permission is through the use of policy files. Policy files are configuration files that specify which permissions are granted to which applets. These files can be used to grant applets permission to access specific resources or perform certain tasks, such as accessing the user's file system or interacting with the network. In addition, some web browsers provide a sandbox environment for running applets. This sandbox environment restricts the applet's access to resources and prevents it from performing certain tasks that could be harmful. However, some browsers allow users to adjust the security settings and grant additional permissions to applets if desired.
It is important to note that granting applets permission to perform tasks outside of the normal security limitations can be risky, as it could potentially allow malicious applets to perform harmful actions on the user's system. Therefore, it is important to only grant permissions to trusted applets from reputable sources.

This section discusses first the Toolkit getImage methods and then the Applet getImage methods. The Toolkit class declares two getImage methods:

1. Image getImage(URL url)
2. Image getImage(String filename)

Here are examples of using the Toolkit getImage methods. Although every Java application and applet can use these methods, applets are subject to the usual security restrictions. In particular, untrusted applets can't successfully specify a filename to getImage because untrusted applets can't load data from the local file system. You can find information about restrictions on untrusted applets in Security Restrictions .

Toolkit toolkit = Toolkit.getDefaultToolkit();
Image image1 = toolkit.getImage("imageFile.gif");
Image image2 = toolkit.getImage(
new URL("http://java.sun.com/graphics/people.gif"));

The Applet class supplies two getImage methods:

1. Image getImage(URL url)
2. Image getImage(URL url, String name)

Only applets can use the Applet getImage methods. Moreover, the Applet getImage methods do not work until the applet has a full context (AppletContext). For this reason, these methods do not work if called in a constructor or in a statement that declares an instance variable. You should instead call getImage from a method such as init.

Click the Quiz link below to check your knowledge of applications, applets, and the Java API.
Application Applets - Quiz

[1] Java interpreter: The Java interpreter is a program responsible for translating Java bytecode into native code that can execute on a given platform.

[2] AppletViewer: AppletViewer is a utility included with the Java Development Kit that allows you to test applets without using a Web browser.