Teaching programming requires imparting understanding of a dynamic system based on static program text. This is often best done by running programs, which can be done both by instructor and student. The programming environment is often very complex, and may hinder understanding of a lesson that does not involve the environment. This paper describes how the programming environment can be hidden, so that program compilation/execution is reduced to a single-click from a Web page. Programs can be modified within a Web page and re-executed again with a single-click, improving prospects for experimentation and student-centred learning.
One of the major features of the Web is the ability to follow links to a wide variety of content using a single-click. This feature has proved so desirable that ecommerce models built on "single-click purchases" have even been patented.
The Web has been used for conveying teaching materials, and there is a huge literature on the courseware available on the Web (previous WebNet or any other Web conferences such as Asia-Pacific Web have conference sections devoted to the use of the Web for education). A large amount of this literature is concerned with techniques and application of learning models for structuring the courseware so that single-click navigation is profitable. Some literature uses plugins of various kinds (such as ShockWave) to deliver certain effects judged to be of educational value.
Computer programs are represented statically, but can only be understood by dynamic execution. Teaching programming is often regarded as a laboratory subject due to the need to run and to experiment with programs. Books, university courses and most instructional material are unable to aid directly in this. Programs that appear in texts are often given separately on CDROMs or are available for FTP download. The intent is that students can then run these programs in their local environment without having to retype the entire program.
Computer courseware on the Web has similar issues: where program concepts are discussed there is often a means of accessing complete working programs, either by cut-and-paste or by FTP downloads. Most HTML browsers will allow cut-and-paste, but some plugins such as readers for PDF documents may not allow this technique and have to rely on other methods.
An experienced programmer will not have difficulties in copying
and pasting example programmers into their favourite programming
environment, and will put up with various arcanities such as
the Java main() method in order to play with new
concepts.
The novice on the other hand faces a large number of difficulties just in dealing with any programming environment
This paper reports on a project to aid in learning Java by offering
single-click compilation and execution of programs displayed
in Web pages. The programs are given in TextArea's
within browsers so that they can be displayed and
edited (for experimentation).
These are compiled on a server and delivered to
the browser to be run as WebStart applications [webstart].
The editing environment is familiar to users from previous experience
with forms, while the compile and execution environments are hidden.
In [Newmarch] we reported on a scheme to allow C programs to be displayed in a browser, edited and then compiled and run back on the browser side. There are many security and trust issues involved in this:
In addition, there are many environmental issues. Simply, C code is usually compiled to code native to a particular processor (or perhaps emulated), and is not portable between either processors or operating systems. This generally means that compilation and execution must be done on the same machine. (Trying to deal with the combination of operating systems and processors for a cross-compiler system would be horrendous.) This machine would either be the server (too risky) or client.
The scheme used in [Newmarch] did solve the problem, using proxy servers running on each browser machine with a security exploit on the servers that made them execute code locally rather than transmitting it - a weakness in the specification or implementation of those particular proxies. This was extremely complex to set up and required administrator access to student machines, and was fragile in use. The scheme was used successfully for a few years, and then broke due to an unknown cause and could never be made to work again.
During the period in which it was working, both I in my lectures and students in labs used the mechanisms extensively. One click live demonstrations of programs proved very effective, especially when they could be edited in place to show variations, re-executed with just another click.
A program needs to be displayed in a browser or plugin called from the browser and executed locally. Intermediate steps may involve compilation to executable or intermediate code, and may or may not involve round trips to a server.
Local execution means that the program must be run on the same machine as the browser, preferably in the same execution environment as the browser. It should be possible to interact with a program using keyboard and mouse. These rule out a number of possible technical solutions:
nobody
Local compilation and execution may be preferable for client-side security. However, the variety of possible compile and execution environments makes this infeasible for all but the most common interpreted environments. Programs in a language such as C, with a multiplicity of compilers, need a high degree of local customisation. Languages with platform independent intermediate forms such as Java and Emacs Lisp can be compiled on servers and delivered to local platforms for execution.
Execution of all but the most trivial programs will require access to local resources, and this may be problematic for security reasons. For example, a Java applet cannot be used to demonstrate file I/O using the standard applet sandbox security model since file I/O is disallowed under this model. There are weaker forms of the sandbox model that can be used in recent versions of Java. This requires trust in the executing code, and this trust must be present for all other possible solutions.
The Java Network Launching Protocol (JNLP) is designed as a way
to download and run Java applications by clicking on a particular
kind of URL. URL's with extension .jnlp are associated
in a browser to a helper application webstart.
A JNLP file contains information about jar files and any
other files (such as appropriate version of the Java runtime)
required to run the application. The helper checks local system
resources and downloads any required classes or resources before
starting the application.
JNLP allows a one-click method of downloading software and running it locally. It takes care of ensuring that dependencies are met and a suitable runtime is present. It will download just the minimum to ensure this.
It has a security model that restricts code to a sandbox model unless the code is signed, in which case it may be allowed to run with no restrictions. This is a very coarse-grained security model, with far less options than are allowed with the Java 2 security model. The options are not appropriate for Jini code, for example, which should often run in a "sandbox with networking". Nevertheless, the all-permissions model does allow trusted code to run and do interesting things locally.
By combining the ideas from our earlier work with WebStart, we can get a one-click interactive environment for demonstrating Java programs. The "compile once, run anywhere" property of Java means that most of the complications of languages that compile to native code can be avoided. The one-click environment is built from the following components
TextArea is used to display a Java program
within an HTML Form.
This can be edited to demonstrate variations, or submitted
as is
text/plain format
jar file containing the compiled classes
A screen shot of a browser and the application called from this is
The interaction between the components of this are
A response can then be sent as a JNLP file back to the browser, which references the jar file. The browser will call WebStart which will fetch the jar file after checks on the local system. After this, the jar file is no longer required on the server.
Managing this bumps into the standard web problem of stateful access in a stateless system. The response of a JNLP document ends a request session from the browser, and the interaction between WebStart and the server is a separate session. The current implementation handles these issues in the following manner
To illustrate a programming concept it may not be necessary to show a full program. A couple of classes, or perhaps just some methods of a class might be enough. The current implementation uses the class as minimum unit. That is, one or more classes can be shown in TextArea's for editing. This may not be enough to actually run a program, and so additional classes may be included as hidden fields.
For example, a program to show a Button in a Frame,
and a listener that brings up a JDialog is
import java.awt.*;
import java.awt.event.*;
public class Test extends Frame implements ActionListener {
public Test() {
Button btn = new Button("Press me");
add(btn, BorderLayout.CENTER);
pack();
btn.addActionListener(this);
}
public void actionPerformed(ActionEvent e) {
javax.swing.JOptionPane.showMessageDialog(null, "alert",
"alert", javax.swing.JOptionPane.ERROR_MESSAGE);
}
}
This will not run as is: it has no main() method.
It also has no "window closing" code. If these are not the purpose
of that particular lesson, they can be placed in a separate class
import java.awt.event.*;
public class Main {
public static void main(String[] args) {
Test t = new Test();
t.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
}
);
t.setVisible(true);
}
}
Test can be shown in a TextArea,
the class Main can be included in a hidden input field.
WebStart makes the assumption that downloaded programs use a GUI
interface. This is not in the specification, and is just ignored as
an issue. The Sun implementation of WebStart just discards I/O
involving System.{in,out,err}. Other possibilities
might have been a flag within the specification to include
this environmental possibility, or to have an equivalent of
the Netscape "Java Console" to handle this form of I/O.
There are many situations where one might want to avoid this assumption
Vector
would not want the complication of GUI code
Objects such as System.in are declared final
and so cannot be reassigned directly.
However, there are methods such as System.setIn(...)
that can be used to reassign these objects. Using these methods,
it is not too hard to build a "GUI wrapper" that consists of a
Text or JText with I/O linked to
System.{in,out,err} by pipelines. The wrapper can
be used as the main controller from a hidden field so that it
need not be visible to the student.
I currently teach a subject "Distributed Programming using Java". The Web lecture notes for this subject are being modified to allow one-click execution of programs (after WebStart has been installed). A sample lecture is at http://jan.newmarch.name/distjava/socket/lecture.html
Using this, it is straightforward to demonstrate TCP and UDP clients and servers, and modify the code in place. The subject will next be taught in August, and usage of this will be monitored throughout the teaching period.
A system is running and is being used to modify existing teaching material of the author. Some parts of the online Java Tutorial are also being modified (in private copies) to demonstrate that this system is not tied to a particular teaching style.
There has been substantial work done on a teaching environment called BlueJ. This is a standalone system at present. Investigations are being made into integrating BlueJ and WebStart technologies to allow Java courseware on the Web to be imported into the BlueJ teaching environment.