Why is there still interest in (and lots of questions about) applets?

[Pat Farrell]

Elsewhere, I've noted that there is a lot of interest in RMI, which I consider a dead technology within Java.

This section is, of course, dedicated to applets -- small java programs that execute in the user's browser. I spent a lot of time last century developing applets, and in the end, the project failed. Applets are a much better idea than they are an actual, production ready technology. So I have to ask the same question, rephrased for this forum section:

Since Applets are a dead technology, why are people trying to use them today, in 2012?

Recently, the Wall Street Journal reported on a recent "Mac virus" that is making a lot of buzz both in the industry and in the mainstream press. See
http://allthingsd.com/20120406/whats-this-a-mac-virus-no-actually-its-a-weakness-in-java/

First, its not a Mac virus. Its a Java bug triggered by the use of applets.

The article's recommendation is that you disable applet execution in your browser. I agree, this is a reasonable suggestion. Apple also has a patch to Java, which solves it. But I think a cleaner, more long term solution is to just prohibit applets.

So why are they alive?

[Paul Clapham]

A lot of those questions are because people are still teaching from the same books they bought in 2001. Same reason as why RMI, and why JSP scriptlets. You'll remember that early Java books covered applets before you got to Chapter 3, right?

[Pat Farrell]

Yes, I remember, and IMHO, all those books should be used to start fires to keep students warm.

There is more than enough material to cover in Java, why waste the student's time learning this stuff that industry rejected last century?

We no longer teach courses in steam locomotive design, why teach RMI and Applets?

[Michael Dunn]

If I remember correctly, beginning classes were taught VB6 until MS killed it off for .net,
so applets will probably still be taught until also killed off i.e. the educators would then
be forced to learn/read up on another language.

[Walter Gabrielsen Iii]

Why shouldn't there be an interest in Applets? They are more interactive than images and more useful regarding threads, number crunching, and tools than Flash. Have you seen the explosion of popular Flash games on the internet? Java has its place and Flash has its place.

You think that Applets are dead because they're an old technology? Well, A lot of the web standards are old technology. It doesn't mean they're dead it means they are reliable and established.

Yes Java Applets have been used in hacker attacks, and that's why they are crippled today as far as security permissions go. Disabling them is the right thing to do I agree. However, I would think it would be plainly obvious to the user if and when they actually want to use an Applet.

Mysterious, invisible applet that you can't see and was launched by a banner ad? No thank you!

Visit a Physics web page dedicated to an Applet depicting the motion of objects with interactive controls? Yes I would consider that a trustworthy Applet.

Applets are also a gateway between Java ME and Java SE. Applets and Midlets, as they are called, both have a similar starting model:

Applet:
init(),
start(),
stop(),
destroy(),

to Midlets:
[constructor],
startApp(),
pauseApp(),
destroyApp()

So if you program in either Applets or Midlets you'll see that switching between them is not hard from the technical perspective (Though you'll miss the optional packages from Java ME's MSA 1.1 but you gain the full Java SE library in Applets -- a mixed blessing if you want SVG or 3D).

[Pat Farrell]

Walter Gabrielsen Iii wrote:You think that Applets are dead because they're an old technology?

Not at all. I like old technology. I'm even old myself.

I think applets have been dead for all of the century because they no longer solve the problem we have. Running a bit of Java inside a browser talking to the web server is no longer interesting. The support issues (which browser supports what, how do you get through the firewall, etc.) are impossible to solve in general.

While I dislike Javascript as a language, its where the industry has moved.

Many folks here use applets because they are taking a introductory course in Java, and back when the course was designed, books written, etc. it looked like applets would be a good solution. They have not. But the courses and books still cover it as if it was important.

[Bear Bibeault]

Exactly. Applets aren't dead just because they're old, they're dead because they're a lousy solution to the problem that they are trying to solve. There are better solutions in place that make most of what applets try to accomplish obsolete.

Do they have their place? Sure, until something even better comes along. But they're a niche of a niche of a niche in arena of modern web development.

[Walter Gabrielsen Iii]

Why do you think Applets are web applications? You seem to think that Applets are there to run communications back and forth between the server and client. I don't see Applets as web applications. If you want a web application then you should use Java Web Start instead of Applets or sign your Applets.

True, there are some provisions in Applets that allow them to grab an image or sound file from the relative local directory where they come from (the code base URL) but otherwise there are specific Java security mannager settings there to keep Applets contained in their own little worlds and out of people's systems or networks.

Applets, to me, are like self-contained little programs whose function stops at the rectangle border of the embeded view area. Applets are like HTML files in that you make one self-contained page (or applet) per topic. And then only add a local image or two for presentation.

If you want to run, say, a science simulation in a web page on your browser instead of using images then the Applets are your friends.


How can "modern" web design help the user? If I think about it from a compatibility perspective, there's nothing better for web development other than static text or server-side scripts to present text. Everything else (Flash, Java, Silverlight, and whatever else... Client-side Scripts... even Image formats) needs some kind of plug-in or build-in browser support to run. Some things are actually being taken away not just Applets but all the plugins, scripts, and even some server-side calls. Because No-Scripts, or whatever new security plugins get developed, know that all of these programs and actions are untrustworthy.

[Walter Gabrielsen Iii]

Okay here is why Applets are a security hazard. Up through Java SE 1.4 the most vital method that checks the Security manager to see if the Application has permission to do a restricted action was not marked final.

Methods marked final in java can't be overridden. Otherwise you can just say do this (Note: this is not the actual java code):

SecurityManager mySecurity = new SecurityManager() {
    public boolean canIDoHorribleThings(myPermissionSlip) {
        return true;// always return true.
    }
}

Apple stopped developing Java on Mac OS X after Sun (then owner of Java) sued Apple for adding Mac-only special extentions to the Java API on their platform. That version was 1.4 and had the security vulnerablility. Apple realized too late about this and so, embarrassed from the hack, Apple finally turned Java Mac over to Oracle (Java's current owner) to develop, and the problem has been fixed.

[Bear Bibeault]

Walter Gabrielsen Iii wrote:If you want a web application then you should use Java Web Start ...

Wow, you are really misinformed here. JNLP (Java Web Start) has nothing at all to do with web applications. It's a way to download desktop apps to run on the local client.

As for the rest, you can laud the benefits of Applets all you like, but the fact remains that they are viewed as a failed technology and they are rarely used.

[Bear Bibeault]

Walter Gabrielsen Iii wrote:Apple stopped developing Java on Mac OS X after Sun (then owner of Java) sued Apple for adding Mac-only special extentions to the Java API on their platform. That version was 1.4 and had the security vulnerablility. Apple realized too late about this and so, embarrassed from the hack, Apple finally turned Java Mac over to Oracle (Java's current owner) to develop, and the problem has been fixed.

Another piece of misinformation. Apple developed Java for Mac OS X up until 1.6, and still issues updates for 1.6. As of 1.7 they have turned that responsibility over to Oracle.

Perhaps you are mistakenly thinking of Sun's beef with Microsoft for not following the Java specifications.

[Walter Gabrielsen Iii]

Really Apple rose above Java 1.4? Last year when my Aunt bought her new iMac from the apple store it came with Java SE 1.4.

My only mac was 1 2003 iMac that also came with Java SE 1.4... You can understand my confusion, yes?

[Walter Gabrielsen Iii]

Yes I do know what Webstart is. In fact the JNLP file format is there specifically there for use on the web. I mean if you want to run Java outside the security sandbox you need to run it as a full program. Just because Applet is part of Java SE doesn't mean you get a free pass to use most of the API. The Security manager blocks most of it you know?

[Bear Bibeault]

Walter Gabrielsen Iii wrote:You can understand my confusion, yes?

Not at all. It's easy to find information on Java for the Mac. And how you came to the conclusion that they not only stopped at 1.4, but as the result of some fictitious lawsuit, is beyond me.

[Bear Bibeault]

Walter Gabrielsen Iii wrote:Yes I do know what Webstart is.

The perhaps it's "web application" that confused you?

[Walter Gabrielsen Iii]

The Java tutorial recommends using Java Web Start as the new way to launch Java on the web. Isn't the web start really just the xml-based JNLP interacting with the Java plugin to grab the Java application and save it to the hard drive for launch? The tutorial even recommends that Applets launch in the new way under a JNLP file to avoid security restrictions.

Deploying an Applet

Java applets can be launched in two ways.

1. You can launch an applet by specifying the applet's launch properties directly in the applet tag. This old way of deploying applets imposes severe security restrictions on the applet.
2. Alternatively, you can launch your applet by using Java Network Launch Protocol (JNLP). Applets launched by using JNLP have access to powerful JNLP APIs and extensions.

[Walter Gabrielsen Iii]

Bear Bibeault wrote:

Walter Gabrielsen Iii wrote:You can understand my confusion, yes?

Not at all. It's easy to find information on Java for the Mac. And how you came to the conclusion that they not only stopped at 1.4, but as the result of some fictitious lawsuit, is beyond me.

Because I found the same Java version in a new iMac almost a decade after my original iMac, and years ago I heard that Apple was dropping Java support. I can't keep track of all the dates of when things happen.

For the long story:
In the late 1990s Sun Microsystems, java's original developers, declaired that all implementations of Java must be "compatible" with each other, implement the same API, and have no platform specific extensions. In 1997 Sun Microsystems took Microsoft to court for adding Windows only features to Microsoft's implementation of Java. Sun won the case. Microsoft stopped shipping Java with Windows and ever since then Java for Windows has been written by Sun Microsystems which later merged into Oracle.

I can't find anything at the moment but in the past I was almost certain that Apple Computer's, then classic OS, java plugin : "Mac OS Runtime for Java" was also guilty of adding platform specific features too. I thought Sun went after them next, after Microsoft. I was almost sure that Apple would act in the same way as Microsoft. Seeing as how Steve Jobs hated everything anyway: Java, Flash, ect... and took them all off apples Ipad/phone/whatever mobile platforms.

My idea of the time line goes something like this:
Geek developers for obscure platforms nixed - Java 1.1
Microsoft nixed - Java 1.3
Apple nixed - Java 1.4

years later:
Android nixed - date to be announced?

[Tim Moores]

Walter Gabrielsen Iii wrote:I thought Sun went after them next, after Microsoft.

They didn't.

My idea of the time line goes something like this:
...
Apple nixed - Java 1.4

As Bear said, that never happened.

[Darryl Burke]

Applets still have their uses. I maintain a small site for a not-for-profit social organization, on the free sites.google.com. I can't use JS nor databases, so when I wanted a member list with a name format option of First Last / Last, First sortable by name, location etc. my only option was to write a JApplet that reads its data from a .csv, easily maintained with Excel, and displays it in a JTable in a JScrollPane.

I did have to go through a few hoops because of the silly way Chrome covers the entire Applet area with a dirty-yellow jigsaw-puzzle piece if Java is disabled or not available, resulting in the plain html inside the APPLET tags not being displayed, but that could be overcome with a page that uses another Applet to redirect to the main member list page, with a link to a static list (actually an image in a scrollable DIV) that doesn't require Java after the closing APPLET tag.

I do realize that this constraint doesn't apply to commercial sites; but as long as needs like mine exist, Applets can't be called useless.

[Marcus Kelvin]

I'm one of those people taking an "Intro to Programming in Java" uni course that includes a lot of applet exercises.

I'm not bothered one way or another about that. I actually had to enable my browser plug-in to do the material and I can't recall not having it enabled being much of an issue before that, so I guess it does demonstrate just how "dead" applets are in terms of general usage.

OTOH, since I already have a lot of programming experience in other languages, including GUI stuff, and have done a fair bit of web-dev work, I found applets pretty interesting...portable little GUI apps that can be run stand-alone or in a browser, and that can have data bundled with them in a .jar file. It's a nice idea.

Pat Farrell wrote:I think applets have been dead for all of the century because they no longer solve the problem we have.

I don't think that is the reason at all. Ideally (that is, sans deployment issues) they seem to have a lot of potential to do certain particular things, almost as much now as 10-15 years ago.

While I dislike Javascript as a language, its where the industry has moved.

I quite like js and have been using it for years; I think in general it is a better "solution" to client side dynamic content than applets, partially because it is better integrated into the page, and partially because the nature of the language better suits the scale of most client side programming. However, for certain particular things involving say, complex widgets, applets have a very clear advantage because of the whole swing library; you can very easily do things that would be a serious (and problematic) undertaking in javascript (where you'd also run into a disadvantage of integration into the page and browser, namely, browser heterogeneity and awkwardness). All that is still very real. I imagine for more intensive graphical stuff flash is better, but for general GUI-ish stuff, the applet concept seems ideal.

I'm guessing what most likely killed applets was portability issues/user hassles with java itself. That's nothing to do with the applet concept or what kinds of problems they potentially solve. If ten years ago oracle had created a lightweight, stand-alone (as in, not dependent on the system JRE), easily installed plug-in like Adobe, things might have been different. Of course, I imagine there may be some technical barriers to that (much in the way Android can't run applets).

Another big issue: security. I was mortified when I read that a signed applet could have access, eg, to the filesystem and the clipboard. I'm okay with transmitting a password or credit card number on an individual basis over https, but I don't care who you are or who signed your certificate, there is no way I want ANY browser app to EVER have access to the clipboard or filesystem. No doubt those possibilities scare people off. This was a very poor design choice. I have no idea why someone would believe anything else. Sometimes, appropriate limitations are better than carte blanche.

Many folks here use applets because they are taking a introductory course in Java, and back when the course was designed, books written, etc. it looked like applets would be a good solution. They have not. But the courses and books still cover it as if it was important.

Again, although I doubt I will have much use for them in the future, I'm actually a little saddened by that and enjoyed learning about them. I think there is some significance attached to history in an academic environment, and so you learn not just the latest trends, but do some "archaeology" as well. Understanding and having a knowledge of history can be a useful tool (eg, it gives you a better perspective on the latest trends). Someone also said something in this thread about "educators needing to learn new technology" -- I think that begs the question that they haven't, when it seems more likely that in fact they have, but do not bring it into every 200 level CS course for a reason.

Also, WRT to applets in particular, probably people who really are brand new to programming would find them a exciting but not as difficult as the alternatives (eg, the way in which they bridge straightforward GUI stuff and the murkier world of the browser). Maybe that's motive enough to use them as learning exercises. I felt genuinely sorry for the complete neophytes in the course; some of them seemed justifiably overwhelmed at points. They might as well get to have some fun at the end and see concretely the purpose of all that "OO mumbo-jumbo" they learned.

[Bear Bibeault]

Tim Moores wrote:

Walter Gabrielsen Iii wrote:I thought Sun went after them next, after Microsoft.

They didn't.

My idea of the time line goes something like this:
...
Apple nixed - Java 1.4

As Bear said, that never happened.

Yes, please stop posting flights of fancy as if they were facts.

[Walter Gabrielsen Iii]

Bear Bibeault wrote:Yes, please stop posting flights of fancy as if they were facts.

Very well, I concede that neither Sun nor Oracle ever sued Apple during the run of Java SE 1.4, and that Apple Computer didn't stop developing Java SE at version 1.4.

I still maintain that consumers were, in the past few years, buying Macs from Apple with very old versions of Java pre-installed on them.

[Bear Bibeault]

That depends upon which version of OS X is installed. For the most recent versions up until Lion, 1.6 is pre-installed. For Lion, Java isn't installed by default, but it automatically asks if you want to install 1.6 upon its first attempted use.

[Tim Moores]

Walter Gabrielsen Iii wrote:I still maintain that consumers were, in the past few years, buying Macs from Apple with very old versions of Java pre-installed on them.

Let's look at the facts of that, then. Java 5 came out in 2004, and was available beginning with OS X 10.4 which came out in 2005. Java 6 came out in 2006, and was available beginning with OS X 10.5 which came out in 2007. Java 7 came out in 2011 and is indeed so far not available in a released version for OS X - Java 6 still has to do; that can't possibly be what you mean, can it? So which are these "very old versions" "in the past few years" you speak of?

[Jayesh A Lalwani]

Marcus Kelvin wrote:
I quite like js and have been using it for years; I think in general it is a better "solution" to client side dynamic content than applets, partially because it is better integrated into the page, and partially because the nature of the language better suits the scale of most client side programming. However, for certain particular things involving say, complex widgets, applets have a very clear advantage because of the whole swing library; you can very easily do things that would be a serious (and problematic) undertaking in javascript (where you'd also run into a disadvantage of integration into the page and browser, namely, browser heterogeneity and awkwardness).

Really? I admit that I haven't used Swing/Applets in 12 years, and I have been building apps using HTML/javascript all this while. It seems to me that you can do everything that applets can do GUI wise, with HTML/javascript. And javascript widgets have leaped ahead with the availability of libraries like JQuery/Scripatlicious/etc.

Are there any specific examples of things that can be done better in Swing?

[Walter Gabrielsen Iii]

Jayesh A Lalwani wrote:Are there any specific examples of things that can be done better in Swing?

In a word: Threads. I don't know how far other client-side scripts have advance, but, at least years ago, Java's main advantage for interactive content was its native support for multi-threading.

On the other hand, Applets are known keyboard traps (you can tab into Applets but not out of them) which is a problem for creating accessible web content that relies on keyboard-only access.

That's why Applets should only ever be used on their own specialty pages where the Applet is, in fact, the main purpose of the page -- That way people can always browse away from the page or, as a last resort, close the browser window to escape from the Applet.

[Walter Gabrielsen Iii]

Tim Moores wrote:

Walter Gabrielsen Iii wrote:I still maintain that consumers were, in the past few years, buying Macs from Apple with very old versions of Java pre-installed on them.

Let's look at the facts of that, then. Java 5 came out in 2004, and was available beginning with OS X 10.4 which came out in 2005. Java 6 came out in 2006, and was available beginning with OS X 10.5 which came out in 2007. Java 7 came out in 2011 and is indeed so far not available in a released version for OS X - Java 6 still has to do; that can't possibly be what you mean, can it? So which are these "very old versions" "in the past few years" you speak of?

Yes, Apple placed new Java releases to go with its release of new versions of Mac OS X. And Apple hates its customers and drops its support for older Mac OS X versions whenever it releases a new one. You need the new OS to use the new Java version -- If you got an older Mac OS X version on your iMac you might be forever trapped using the version that came with your system (unless you buy the new version of Mac OS X). Also Mac OS comes with previous versions of the Java engine inside of its system folder so if just one of them has a weakness attackers could exploit it.

After looking it up on everymac.com -- the site that lists tech specs for all Macs ever made, My old iMac that I bought new in the Apple web store in 2003 it turns out that it was actually the Summber 2001 iMac model (which was still the latest iMac model at the time I bought it) it came with Mac OS 10.1 and which I later upgraded to Mac OS 10.2 which afterwards had in its system folder: both Java SE 1.3 and 1.4. I couldn't upgrade Java beyond that because it required a later version of Mac OS X.

I can't tell by looks what model my Aunt's iMac was, based on appearance, because all of the big-screen iMacs on everymac.com from about late-2007 to the newest iMac on Apple's website today all looks the same to me. I'm going to say she bought it around 2010-ish and it came with Mac OS 10.4 so it should have had at least Java SE 5 -- it might have been a refurbished model. It did also come with Java 1.4 in the system folder.

That Java 5 was actually available in 10.4 -- That's actually good for me to know since I base my programming decisions on compatibility, ability to port to Java ME, and my experiance with web standards (where it takes about 3-5 years (sometimes even 10 years) for new technology to reach the mainstream market not just geeks who update their plug-ins and OS regularly). I've seen how people who don't know about technology, and sometimes even those who do, usually end up with old technology even when they go out to buy a new computer.

[Jayesh A Lalwani]

Walter Gabrielsen Iii wrote:

Jayesh A Lalwani wrote:Are there any specific examples of things that can be done better in Swing?

In a word: Threads. I don't know how far other client-side scripts have advance, but, at least years ago, Java's main advantage for interactive content was its native support for multi-threading.

Meh. IMO, Using threads for UI seems to be overkill . If all you need to do is update the UI asynchronously, timers are more than sufficient, and do not have the horrible synchronization problems that threads have.

Walter Gabrielsen Iii wrote:
On the other hand, Applets are known keyboard traps (you can tab into Applets but not out of them) which is a problem for creating accessible web content that relies on keyboard-only access.

That's why Applets should only ever be used on their own specialty pages where the Applet is, in fact, the main purpose of the page -- That way people can always browse away from the page or, as a last resort, close the browser window to escape from the Applet.

Also, applets look "out of place" in a page that has HTML elements. The way Java renders the controls doesn't look like the way browsers renders the same controls. And, you cannot use stylesheets which breaks the pardigm that web development that is moving towards. The elements on the page should only define what to show the user. How the element looks is controlled by the stylesheet. If you want to change the look & feel, all you do is update the stylesheet and your entire site changes. You can't do that with an applet. You have to incur additional development cost to modify each applet that you developed

[Walter Gabrielsen Iii]

Jayesh A Lalwani wrote:Also, applets look "out of place" in a page that has HTML elements. The way Java renders the controls doesn't look like the way browsers renders the same controls. And, you cannot use stylesheets which breaks the pardigm that web development that is moving towards. The elements on the page should only define what to show the user. How the element looks is controlled by the stylesheet. If you want to change the look & feel, all you do is update the stylesheet and your entire site changes. You can't do that with an applet. You have to incur additional development cost to modify each applet that you developed

How interesting I should write this down. I know that Java doesn't do CSS stylesheets because it has its own internal 2D drawing system. Just about all it can do, under high security, is poll its own param tags.

But Applets do have a link to the outside world. I wonder if it could be possible to use advanced CSS Selectors and Generated content, or Javascript DOM, or a server-side script to send in style information to Java.

Of course it would be extra work for the programmer to map css to Java 2D and set up the dynamic but it is possible.

Thank you so much! You've given me something to think about and add to my list of need to do things to make a high quality app.

[Jayesh A Lalwani]

That's interesting. It might be possible to make an applet look like the HTML page. By default, all applets look like they are aliens. You might be able to make the controls look just like the controls on the page using heavy customization.

However, it will require a lot of work to make the applet look like they are at home in all browsers. You cannot do it without breaking the WORE paradigm. You would need differrent implementations for differrent browsers.

[Pat Farrell]

Jayesh A Lalwani wrote:However, it will require a lot of work to make the applet look like they are at home in all browsers. You cannot do it without breaking the WORE paradigm. You would need differrent implementations for differrent browsers.

Exactly. If you need different implementations, why do it in Java at all? Use a javascript framework such as jQuery.

There is a version of Angry Birds that runs purely in the browser, using javascript and other HTML5 facilities.

Applets solve a problem that no one has had this century. Other tools do the same thing without the problems of applets.