I'm on the way of learning Java myself. I find most of texts giving emphasis to Java applets. I got confused about the importance. Is it something widely used? Do I need to spend more time on it?
9 Answers
As one of the most experienced applet developers1 willing to help on public forums (e.g. the Oracle forums or Stack Overflow), it saddens me to see new students 'tossed in at the deep end' to learn how to make an applet.
The reasons are multiple, but first, I'll look a little at the history of applets and why applets were ever considered a good idea for teaching small, simple projects.
Applet vs. Frame
The simplest applet is:
import java.applet.Applet;
import java.awt.Label;
public class HelloWorldApplet extends Applet {
@Override
public void init() {
add(new Label("Hello World!"));
}
}
Looks simple, right?
But an applet gets a size & position on screen from the HTML that loads it. So an applet also requires a little HTML E.G.
<html>
<body>
<applet
code=HelloWorldApplet
width=400
height=200>
</applet>
</body>
</html>
This makes the total for a working applet 17 LOC. Not looking quite so simple now. Worse, many developers think 'any old mark-up will do' when that is very much not the case. Missing opening or closing elements make the HTML invalid and how a browser will interpret it is anyone's guess.
Compare that to an application that behaves in as smooth a manner:
import java.awt.Label;
import java.awt.Frame;
public class HelloWorldApplication {
public static void main(String[] args) {
Frame f = new Frame();
f.add(new Label("Hello World!"));
f.pack();
f.setVisible(true);
}
}
So, while it takes just 9 lines of code for the simplest of
applets (even including the @Override notation), while 12 LOC for
the application doing the same thing, add the HTML and it becomes
17 lines for applet/HTML vs. just 12 LOC for the application.
AWT vs Swing
Time moves on, and the Swing component toolkit was introduced as a replacement for AWT. Nobody uses AWT anymore. Most Java GUI developers started using Swing, and those that have used AWT have largely forgotten the fine details.
This is relevant to the student in terms of getting help when they get stuck. It does not matter who we are, when approaching new areas of CS, we all tend to reach for whatever resources might help us understand the new technique. For a student the best resources are firstly the text books and class notes, but those typically only go so far at explaining, and the rest is from things like the JavaDocs, the Java Tutorial, searching the net, or asking for clarification on forums.
Those last two are particularly relevant in that:
- There is a slew of extremely poor AWT based code available on the net.
- There may also be some poor Swing based code out there, but usually there is a Swing programmer nearby that can point out the deficiencies in it.
Industry uses Swing and that is all that Swing programmers know and remember. AWT is obsolete, and a dead end in career or learning.
So let's now look at the proper way to write a Swing applet & application. The Java Tutorial warns us that all Swing code should be started and updated on the Event Dispatch Thread, which (ironically) is an AWT based Thread.
A simple Swing applet might then be:
import javax.swing.JApplet;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;
import java.lang.reflect.InvocationTargetException;
public class HelloWorldApplet extends JApplet {
@Override
public void init() {
@Override
Runnable r = new Runnable() {
public void run() {
add(new JLabel("Hello World!"));
}
};
try {
SwingUtilities.invokeAndWait(r);
} catch(InterruptedException ie) {
ie.printStackTrace();
} catch (InvocationTargetException ite) {
ite.printStackTrace();
}
}
}
This is slightly verbose (25 LOC) for strict clarity, but could be reduced to:
import javax.swing.*;
public class HelloWorldApplet extends JApplet {
@Override
public void init() {
Runnable r = new Runnable() {
@Override
public void run() {
add(new JLabel("Hello World!"));
}
};
try {
SwingUtilities.invokeAndWait(r);
} catch(Exception e) {
e.printStackTrace();
}
}
}
It could be further shortened (from 20 LOC) by declaring the Runnable inside the
SwingUtilities method call, but I find that notation to be confusing &
prefer to separate the Runnable into a clearly defined instance.
And now the Swing equivalent application, using the same 'short guidelines'.
import javax.swing.*;
public class HelloWorldApplication {
public static void main(String[] args) {
Runnable r = new Runnable() {
@Override
public void run() {
JFrame f = new JFrame();
f.add(new JLabel("Hello World!"));
f.pack();
f.setVisible(true);
}
};
SwingUtilities.invokeLater(r);
}
}
Just 18 LOC in total.
Not very much coding to see our simple message on screen, in a free floating Swing component.
Embedded vs. not embedded
Security
Why won't the applet load my input file?
By default, Java applets run in a security sand-box that prohibits many actions which might be damaging to other applets, the browser or the user's machine.
While the security sand-box is of great benefit to end-users, it makes the life of the developer difficult. And it has just become that much more difficult in Java 7 update 21.
In Java 7 Update 21 Security Improvements in Detail Markus Eisele notes:
With the introduced changes it is most likely that no end-user is able to run your application when they are either self-signed or unsigned.
While that warning is a little extreme, I agree with the underlying point being made. A user (or in this case you, the teacher) will need to OK some very scary dialogs, and posibly lower the default Java security to an unsafe level, before being able to view an applet.
Error reporting
My applet is broken but shows no errors! Where are they?
The System.err stream used for displaying stack traces appears on the
command line (or in the IDE) when running an application. When a stack
trace occurs in an applet it is sent to the Java Console, which is (by
default) not configured to be shown.
Class caching
I changed my applet but the browser shows the same!
Many times I have responded to applet problems where the questioner swears they have changed the code & recompiled it, yet the browser is still showing the old values. The solution is relatively simple when you know how - flush the class cache from the Java Console. To someone learning, it is typically a complete mystery.
Embedded conclusion
Those 3 problems alone have probably earned me a quarter of the reputation points I've so far earned on this site. They pose huge problems when developing and debugging applets.
But more on Java applets as a web app. component - other cons:
- Either steal the keyboard focus or do not ever get focus by tabbing around the web page.
- Need a JRE (and are not compatible with some tablets and all phones)
- Are not indexed by search engines!
- At one stage, there was an applet/JRE/browser interaction bug for every fortnight that Java had existed. That is in addition to anything related to security or more generally to JWS apps.
- A
Framegets the right size usingpack()but an applet has a size forced upon it by the HTMLwidth&heightspecified in theappletelement. - ..
Conclusion
The question really comes down to:
Are you teaching Java/CS or how to deploy applets?
If the former, use JFrame based applications and side-step all the
problems that are inherent to an embedded app. And don't even consider
teaching AWT components - they are obsolete & Swing takes only a few
more LOC to get something on-screen.
Author Credentials
- So who am I?
- Top ranked provider of answers on Stack Overflow for the applet tag.
- The developer of Appleteer.
- Host of many applets on my site.
- See also the blog post.
-
Thanks for the comprehensive answer. I actually often wondered why applets are not used so often any more. What are the alternative solutions and why are they considered better?– GiorgioJun 3, 2013 at 16:25
-
@Giorgio "What are the alternative solutions.." It depends on what you wish to offer to the user. Worthy of it's own Q&A. But that might be closed, as well. ;) Jun 3, 2013 at 16:33
-
I find it great to develop and test a desktop application and then deploy it as a web application running in a sand box by just changing a few lines of code. I do not know of other technologies offering this. Also, Java is much more robust than JavaScript so I would rather write a Java applet than a JavaScript application. But I know very little JavaScript to have an authoritative option on this. If you know any any useful reading material on the topic (alternatives to Java applets) could you post a link?– GiorgioJun 3, 2013 at 16:41
-
1@Giorgio "I find it great to develop and test a desktop application and then deploy it as a web application running in a sand box by just changing a few lines of code." For deploying Java desktop apps., the best option is usually to install the app. using Java Web Start. JWS works on Windows, OS X & *nix. Jun 3, 2013 at 16:59
-
Thanks, I have already used Java Web Start for an application I have developed a few years ago. I think I used the wrong formulation: I meant I can use the same technology for a web application and for the client of a web application (and for the server, for that matter). Other solutions like JavaScript require a mix of programming languages.– GiorgioJun 3, 2013 at 17:03
Applets aren't used widely these days, so the knowledge won't be that useful. That said, there is little in Java that is applet-specific. It makes no difference if you learn AWT and Swing by writing applets or by writing desktop applications. It's fairly easy to write an application that will also function as an applet.
The main distinction is that you use a different top-level container for applets than for applications. Unsigned applets also have some security restrictions, particularly around IO and networking.
Applets are really just a different way of deploying Swing or AWT applications, where you embed the application in a browser-based environment rather than running as a standalone application.
So my advice would be to focus on Swing (AWT is somewhat outdated nowadays...) and if you need to then you can always wrap the same code in an applet later.
I've written Java code that could run either as an applet or a standalone Swing application, you need literally just 10 or so lines of code to support both.....
If your aim is to learn GUI development in Java, I would say to stay away from applets and just focus on learning Swing the old-fashioned way. I don't know all the ins and outs of Applets and it hasn't affected my job negatively. On the other hand, many games are distributed as applets, as well as the output of Processing. So it's a good skill to have if you want to distribute your work in an easy to view way on the web, but I wouldn't strive to create anything huge within an applet.
(Do note that it's not impossible to port existing code written for the desktop to run as an applet, which is why I suggest you learn desktop development first. You'll learn the concepts but without having to jump through the extra hoops of the special applet GUI code, and the browser interactions.
It all depends on what your intentions are and who your audience is. Since you are just starting out, and if you do not have a project that requires you to project into the web/browser, I would tinker with Swing and learn how that UI paradigm works. When the time comes, you can then learn how to wrap that into an Applet and deal with the deployment issues (security, deployment, platform compatibility, etc). Even if you never use an Applet, or Swing in the future, the core concepts you learn to master Swing (threading, events and listeners, employing a MVC philosophy, basic behavior of UI widgets ....) are useful in almost any UX context.
I would say not, because they're not very widely used. If you're curious, you might want to take a look at them after you've gotten a good handle on Java. They're not terribly hard to understand, but I wouldn't include them on my primary list of things to learn.
From what I've noticed, most web pages don't embed Java applets. The programming environment (at least from a web and server perspective) is moving towards easy-to-write and quick to deploy languages and frameworks such as AJAX and .NET.
Flash is another a big reason Java applets have generally moved out of the spotlight. Flash GUI's are incredibly easy to create and most of the behind-the-scenes coding functionality required for interface stuff is already included. I think the only new Java applet I've seen as of late was a specialized stock tracking program built into Think Or Swim.
But what the hell do I know, I write mostly native applications in C++/ASM. I only use the really high level stuff for interfacing with the code I write in those languages.
That being said, while it's useful to know those older Java features, you should get and read more up-to-date material. Java is an evolving language. You will always have to learn new material with each major release. While I mostly code in C++, I do borrow and implement some concepts and features from Java, so I am familiar with the platform.
Here's some project ideas:
- Combined SSH & Telnet Client.
- Chat program.
- A general purpose calculator and solver (something that has functionality equivalent to that of a TI-82, not Windows Calc.)
- A Java bytecode decompiler.
Feel free to correct me, I'm only 16 and I'm relatively new to the programming world!
-
Also, I believe the reason that these books emphasize on coding Java applets is due to the fact that they used to be pretty popular and were the easiest way to deploy integrated programs into a web-page. However newer technologies have come out and older ones have evolved (such as Macromedia -> Flash) and taken over this role.– user32288Jul 25, 2011 at 3:55
Generally no, unless you have tried all other GUI platforms/frameworks and itching for something different.
Academically speaking, can provide a different perspective of GUI development whether it is for teaching or demostrations (some might say -ve demo :P ).
if you are building a web-based program handling some very confidential information ( such as banking or financial application), go for applets, the fact that it is not widely used, you can take advantage that to at least get away from the sight of common hackers, java has a bunch of methods on which you can encrypt everything when you are transmitting data, also the ui itself will require more efforts before you can decompile a *.class file,
just like how popularity of "Windows" make it as an apple of the eye of the virus authors and hackers, use non-popular technologies to hold them back
-
3
Vector,Hashtable,Enumeratoror rawArrays'instead of the modernCollectionclass alternatives, throw it out immediately.