Download No Slide Title

Resurrecting Applets
Eric Roberts
Professor of Computer Science, Stanford University
ACM Java Task Force Chair
SIGCSE 2007 Symposium
Covington, Kentucky
March 10, 2007
The ACM Java Task Force
The ACM Java Task Force was established in early 2004 with the
following charter:
To review the Java language, APIs, and tools from the
perspective of introductory computing education and to
develop a stable collection of pedagogical resources
that will make it easier to teach Java to first-year
computing students without having those students
overwhelmed by its complexity.
The Task Force released Version 1.0 of its materials in August.
http://jtf.acm.org
Principles
1. Object-oriented approach.
2. Backward compatibility. In order to be forward-looking
and to ensure that our resources remain current for as
long as possible, our baseline version of Java will be
Standard Edition 1.5. However, we anticipate that some
institutions will not be in a position to adopt Java 1.5,
even by the time at which the Task Force materials are
released. For this reason, we will make every effort to
ensure that those resources work in Java releases from
Java 1.2 forward.
3. Minimalism.
4. Conformance.
5. Multiple environments.
The Rise and Fall of the Applet Paradigm
In the early years of Java, applets were responsible for much of
the tremendous excitement associated with the language.
Anyone using a computer who hasn’t been in a cave for the last year
has heard of Java applets. Many people believe that Java is useful only
for applets.
—K. Mitchell Thompson. Tips and techniques for Java
(in Dwight, Irwin, and Niles, Using CGI, 1997)
This situation, however, did not last.
Java applets fueled Java’s initial growth. The ability to download code
over the network and run it on a variety of desktops offering a rich
user interaction proved quite compelling. However, Java’s Write Once,
Run Anywhere (WORA) promise soon became strained as browsers
began to bloat and several incompatibilities emerged that were caused
by the Java language itself.
—Raghavan N. Srinivas, Java World, 2001
The Pace of Change
The biggest challenge involved in keeping applets running lies in
keeping up with the changes in Java. Java evolves rapidly, and
it is difficult for anyone—faculty and browser manufacturers
alike—to keep up. Moving toward plug-in strategies provides
some insulation from the changes, but the user is still responsible
for keeping those plug-ins current.
Java
Applets Are Incredibly Useful
The decline in the practicability of applets is unfortunate, because
they turn out to be incredibly useful:
• Applets make it easier for people developing educational tools
to demonstrate their software on the web. The programs in
the JTF Demo Gallery all run as applets on the web.
• The ability to save programs as applets allows instructors to
make interactive classroom demos easily available to students.
• Having all student programs run as applets make it much
easier for students to share their accomplishments with their
families and friends at other schools.
Reach Out and Touch Someone
Students love the ability to put their work on their web site.
Consider the following e-mail exchange with a student last year:
Hi. I was wondering if you could tell me
how to put the programs I’ve written online
so that they can be run as applets so that
my friends/parents can run them. Thanks.
-- Brittney
Brittney,
A long four-point process showing how it was done at the time.
It should all work.
-- Eric
Fantastic!
Brittney Fraser
Secretary SBSE
CS major
section leader
Applets Are Not Going Away
The good news is that applets are extremely unlikely to disappear
entirely, mostly because doing so is not in anyone’s interest.
• Removing applet functionality makes it impossible to view
web pages that use them, which would in turn make those
browsers less popular.
• Taking out the code to support applets requires work.
Browser developers would surely prefer to invest that effort in
developing new features.
At the same time, the fact that relatively few people are writing
new applets that depend on newer releases of Java means that
developers have no real incentive to keep current.
The bottom line is that applets will continue to run as long as one
is willing to maintain compatibility with old versions of Java.
How Old Is Old?
It is staggering, however, how old the stable Java standard is. If
you walk into essentially any Internet storefront anywhere in the
world—your local Kinko’s, the massive EasyInternetCafe outlets,
a coffee shop that has a few machines—that machine will likely
be running the JDK 1.1 release of the Java runtime. That means:
• No Swing
• No collections framework
• No Java 5.0 generics
• No Scanner class
• Reduced functionality in many classes
Outline of Our Strategy
• At no time did the Java Task Force ever propose that students
would write in anything other than the latest version of Java.
• Initially, we had tried to write the libraries themselves using
JDK 1.1 so that it would be possible to load them on older
browsers.
• We abandoned that strategy for the reasons I cite in the paper:
– The code was too difficult to maintain
– Our code could not serve as a model for students
– Many people somehow believed that it was possible to use the ACM
Java Libraries only with older versions of Java
– It didn’t actually solve the problem
• What we did instead is create an acm11.jar library that
reimplements the features from the JDK subset using the JDK
1.1 model.
The End