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?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
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.
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 ).
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.
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.
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.
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 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
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:
Feel free to correct me, I'm only 16 and I'm relatively new to the programming world!
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:
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.
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:
So, while it takes just 9 lines of code for the simplest of
applets (even including the
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:
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:
This is slightly verbose (25 LOC) for strict clarity, but could be reduced to:
It could be further shortened (from 20 LOC) by declaring the
And now the Swing equivalent application, using the same 'short guidelines'.
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
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:
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.
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.
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:
The question really comes down to:
Are you teaching Java/CS or how to deploy applets?
If the former, use