Paper presented at JICC7, London Jan 27, 2003
This paper describes the framework for a new art form, Rart, where a work of art is created as a Java program.
A work of Rart, called a universe, is a Java class descended from the abstract class Universe. A universe is relatively
easy to program since it only needs a subset of Java.
A Rart universe descending from Universe can be executed in a rartrunner.
They come in several flavors with varying capabilities for the observer to modify the visual impact of the universe
through parameters. A universe can be observed over the Internet using one type of rartrunner. A universe may also
be observed executing in a rartrunner application with a slicker interface and the ability for the observer to
create unique hardcopy of a view frozen in time. The rartrunners also ensure that a universe will remain executable
over time and across new and changing platforms.
Since Rart uses a limited subset of Java and since a Rart universe is an understandable and visually appealing
concept, we suggest that Rart can be used as a vehicle to teach introductory Java, either as a part of a full length
course or as an independent study project.
Rart® (Random Art) is a new form of art. A work in the new art form is a computer program generating dynamically
animated, constantly changing images. The image-generating program is called a Rart universe. One can think
of the computer screen as a two-dimensional window to a visually interesting universe. The creator of a Rart universe
is a rartist. The observer of a Rart universe can interact with the universe through rartist-defined parameters.
Our long-term ambition is to have Rart accepted as a new art form by a worldwide community of rartists. This should
be possible because of the pervasiveness of the Internet as long as the means to become a rartist are simple, inexpensive,
and easily accessible. The creation of a Rart universe should also be easy for any programmer including those inexperienced
or self-educated. This is one reason why we choose the JICC as a forum to introduce Rart internationally and to
have interested Java teachers provide input for further development and dissemination of Rart. If learning Java
for a limited purpose is easy and attractive to students, then it should also be attractive to teachers. We hope
that by showing the mechanics of Rart, as well as providing actual examples, we can show that Rart indeed may inspire
students to dig into the details of an API, that is AWT, the Abstract Windowing Toolkit, and, when they use it,
also pick up the details of the new language.
Anyone with a personal computer and a Java enabled browser (for example, Internet Explorer 4.0 or better) can observe
a Rart Universe over the Internet, since it may execute in an applet environment. Also, anyone may download for
free all software needed for the development of Rart Universes; Minimum requirements are JDK 1.1.8 from Sun Microsystems
and the Rart Development Kit version 2.0, RDK 2.0, from the Rart web pages. (www.rart.com).
A Rart Universe can also, without recompilation, execute in an application environment provided in RDK 2.0. This
gives the observer a better user interface as well as the ability to freeze and print a hardcopy of a frozen view
of the universe. A compiled universe may be distributed for execution as an application with any Java runtime environment
later than, and backward compatible with, JRE 1.3 from Sun Microsystems. The addition of runtime execution features
that may include authentication is the basis for a potential distribution mechanism where a rartist may be remunerated
for his/her copyrighted work. In this paper we discuss the Rart Universe as a Java program, or more precisely,
the Java aspects of any universe developed in the RDK. We also provide the essentials of the various execution
environments for Rart Universes.
This forum has seen many good discussions about Java, its suitability for teaching programming in general and
object oriented programming in particular. By way of introduction, I would like to quote from three papers presented
at JICC6.
In his paper, Dave Collins, Keele University, "contends that Java introduces too many complexities too early
in the learning process". He goes on to describe a learning environment where the first part is based in VBA,
Visual Basic for Applications, and Java is introduced as a remedy for shortfalls in the VBA environment [Java Second,
The Suitability of Java as a First Programming Language]. David Grey and Rob Miles, University of Hull, discuss
the same problem and their approach in developing an interactive web-based course. "By representing real world
objects by pre-written classes, . . . it is possible to use these in practical exercises. Nothing is hidden from
the students when early programs are described in the text, but the students are told which parts they should concentrate
upon. One of the advantages of an interactive course is that students can be given partially completed, working
programs upon which they can base their practical work." [Teaching Java Objectively - Reflections on a Web-based
Java Course]. Finally, I would like to refer to Alan O'Callaghan, De Montfort University. His paper states that
it is "practically impossible to deliver the modern scope of Java within the framework of the traditional
degree structure and the 'bottom up', 'syntax first' approach to teaching . . ." O'Callaghan goes on to provide
three proposals for computer science. One of these is the "Design Studio Concept" where students collaborate
to provide useful and usable solutions under the mentoring of senior teachers. [Redesigning Computer Science].
In order to be productive using Java, you must understand both the application area for which you are to build
a system and the tools, the Application Programming Interface, API, allowing you to build useful systems in the
application area. To learn one API in detail, you will have to learn how to find the documentation, how to read
source code, and, most importantly, find sources where similar applications have been programmed and documented.
This may be a daunting task, especially since the state of the art is a moving target where new APIs are added
to the pool of Java APIs at a rate far exceeding the capacity for formalizing their adoption, as suggested by Collins.
Rart provides a form and a forum for artistic expression. Rart is inspired by the Internet with Java as the enabler.
Students who learn Java for the purpose of Rart, study the Abstract Windowing Toolkit. AWT has been around since
JDK 1.0 (1996) and is stable, well established, and well documented. Students also work developing software that
can be shown in Java applets. This is because I feel that one of the most important aspects of Java is the fact
that it is enabled on the Internet, allowing learning, collaboration, and display of creativity independent of
location and time. I see this as an Internet base for a worldwide Design Studio as proposed by O'Callaghan.
.
I have developed and provided a web-based introduction to Java and Rart since 2000. A recent upgrade of the Rart
software, now RDK 2.0, has resulted in a rewrite of the course. The introductory part of the course can be taken
on the web with no requirement other than a Java enabled browser and JDK 1.1.8 (www.rart.com/JavaIntro030115/).
In my experience, students appreciate being exposed to functioning code and learning that the edit, compile and
run cycle actually works. The fast turnaround resulting from a compile cycle measured in seconds also causes students
to rapidly assimilate what has for some has been a hurdle, new notations and unfamiliar, unforgiving syntax. The
misplacement of a semicolon or the omission of a bracket can be rapidly detected and corrected. Since the student
is learning a small subset well, he or she can quickly with the teachers guidance develop a methodology for researching
the details of an API by going to the source or the original documentation (javadoc). This is altogether a positive
experience for the students and corroborates the observations of David Grey and Rob Miles.
When programming a Rart universe, the student gets immediate visual feedback on what changes have been made. When
finished with the course the student has the satisfaction of having developed a work of art. Granted, the pretty
applets may not be immediately useful to a potential employer. However, the student will have an important skill
needed to become useful and productive, that of mastering the art of discovering what a new API is about. And the
student will have the self-confidence that comes from having created something available for the world to see on
the Internet.
The first Rart implementation, embodied in RDK 1.0, was compatible with JDK 1.0.2, which was released by Sun
in 1996 and used as a basis for the first browser implementations, in particular, Netscape Navigator 2.0. We decided,
however, to make the second implementation of RDK compatible with Java 1.1, which is more applet friendly in that
it allows the consolidation of many class files and resource files in jars. For international deployment, it is
important to minimize download time, and today's browsers almost universally use Java 1.1, which supports jar-files.
For example, Internet Explorer has used the same Java engine since version 3.5. Accordingly we decided that any
Rart Universe should be developed under JDK 1.1.8 which is quite sufficient for most graphics programming and in
itself simplifies matters considerably when spreading the Rart paradigm since mature and stable programs and application
programming interfaces are well documented and readily available.
A Rart Universe is executed in an environment called a rartrunner, and the rartrunner takes care of many of the
tasks that otherwise would have to be programmed individually. In particular, the rartrunner provides all user
interfaces, which actually are limited to mouse activities, and all multithreading. Conceptually, the rartist only
has to consider what his/her universe does as the rartrunner invokes its main cycle over and over again. An explanation
of the parts of a Rart universe should make this clear.
Technically speaking, a Rart universe is defined through the abstract class Universe; that is, any executable
universe (lowercase u) extends Universe (Java class, upper case) by providing the definition of a number of methods
declared abstract in Universe.
Listing of Universe
Universe is defined as follows (a complete and more commented version is available on the Rart web site):
package rartbase;
import java.awt.*;
import java.util.*;
import java.awt.image.*;
public abstract class Universe extends Component{
// Section 1 Identifying the universe
// Three simple public abstract methods getName, getDescription, getRartist
// Section 2 What the universe does
// public abstract methods init, cycle, manageChange
// . . .
// Section 3 uParameters as used in the universe
// uParameters provide the mechanism to interact with the universe
public static final int NUMBER_OF_PARAMETERS = 10;
public uParameter uPs[] = new uParameter[NUMBER_OF_PARAMETERS];
public uParameter[] getuParameters(){
return uPs;
}
// . . .
// Section 4 Utility Methods
// RND, SIGN, and ABS provide a unified way to describe randomness
// printString is used for standardized output of text
// setResourceObjects is used to provide the names of text, images or sounds
// to be used in the universe
// Section 5 Useful variables related to the execution of a universe
// int nc, a counter of cyxcles executed, set by the rartrunner
// boolean doubleBuffer, indicates automatic doublebuffering
// rartrunner, indicates the class of the current rartrunner
// int xm, ym, the size of the current window
// . . .
// Section 6 Methods related to security.
// these methods are of limited interest to rartists
} // End of abstract class Universe
The section headings below refer to the section headings of the code for Universe as listed above.
Identifying the universe
The section is provided to recognize that a universe is a work of art. The rartist gives the universe a name, not
necessarily that of the Java class, and a short description as well as their preferred name or handle. These strings
are presented to the observer in various ways, including an "About" dialog.
What the universe does
The section provides the methods that define the appearance of the universe.
init does all the necessary initiations. It is often done in two parts,
getParam and restart, where getParam
finds the observer-provided initial values of any defined parameters, either from the applet tag when executing
in an applet or for some parameters on the command line for an application. The restart
method is defined here and will do the initiation using current parameters.
cycle(g), where g is a graphics context defined by the rartrunner. cycle provides what is actually showing on the screen using methods for line
and text drawing and image painting provided by AWT, the Abstract Windowing Toolkit. It is up to the rartist to
decide for example if the screen should be completely redrawn each cycle or if the cycle should provide only incremental
changes. As can be seen from the examples, much can be done with the simple methods available. The cycle
method will be programmed using the current values of the screen size provided as xm,
ym (see below).
manageChange(uP), where uP is
a uParameter, is coded to respond changes in the environment or applicable parameters. One uParameter is used by
the rartrunner to indicate a change in screen size. This particular change is likely to result in a call to the
restart method mentioned above. manageChange is typically coded with a
switch with cases selected from the index to the relevant uParameter in the uPs array of parameters.
Parameters as used in the universe
The section defines an array of up to nine elements, type uParameter used for communication with the rartrunners.
A uParameter in RDK 2.0 is of one of two kinds, either an integer in a rartist-defined range, or what to the observer
appears as a selection of a property from a rartist defined set of properties. The rartist defines a string giving
a descriptive name of the uParameter, a short description of its function, and a default initial value. These entities
appear in a standard dialog for modification of parameters. At any time, a uParameter has a current value which
is accessed in the universe, for example, through number.getCur() if number is the name of the uParameter class or through uPs(NUMBER).getCur().For
parameters of the second kind, the uParameter current value is the integer index to an element in the array of
selection alternatives given with the definition of the uParameter.
Some parameters are predefined. A predefined uParameter is cycletime. The rartist defines the range of times between
subsequent calls to cycle, but the name as well as the description is provided in Universe. Undefined elements
of uPs are given the value null. The indices have actually been given
names both as variables and as strings. NUMBER is the index to the uPs element which presumably has been defined
by the rartist as a uParameter to define the number of something relevant for the universe, for example the number
of simultaneous lines in the Lines universe. The string "NUMBER"
is used in the applet tag to set the initial value of the uParameter with the index NUMBER
in the uPs array.
Utility Methods
The section defines some simple functions with names taken from the same functions in QuickBasic. We have also
provided printString as a standard way to output text. Text, which may
be multi-line with explicit line breaks, is output in blue, bold sans serif, and in a point size given by the rartist.
This is also where we handle the import of resources, such as files for text, sound ( au
format in RDK 2.0), or images ( gif format). In the universe, the rartist provides the names of the files with
the specified resources giving a new value to an array defined as protected String[]
reFileNames = null;. The rartrunner gets the list of filenames through public
String[] getreFileNames(){ return reFileNames;} and procures the requested resources which are provided
to the universe through public void setResourceObjects( Object[] os){ resourceObjects
= os; reFileNames =null;}with the array resourseObjects defined
as protected Object[] resourceObjects = null;. The reason the task of
getting resources can not be handled in the universe itself has to do with security. An applet can only have access
to resource files associated with the server from where it was downloaded. The universe is not an applet, but when
it is executing in a rartrunner applet the rartrunner has access and the procurement of resources is allowed. It
is, of course, up to the universe to deal with the resourseObjects, including
the casting of the objects to the correct resource. Since the init method
will set the refileNames, the resources should be processed after init, but before cycle starts repeated
execution. This complication is unfortunate and rather counterintuitive, and we believe beginning students should
refrain from importing resources all together.
Useful Variables
The rartrunners make information available to the executing universe. nc
provides the number of executed cycles, (actually modulo 2000000 to prevent overflow). If the rartist wishes to
execute the universe without the benefit of double buffering, he/she may set doubleBuffer
to false. In some instances it may be useful to know the current rartrunner, for example. if the rartist wants
a slightly different behavior for the universe running in an applet or in an application. However, the most important
used variables are xm and ym,
which give the size of the current window. While the size of the window is fixed in a browser environment, it may
vary when the universe is running in an applet in an applet viewer or when it is running in a rartrunner application.
It is necessary for the rartist to take into account the size of the window especially when its size is changed,
which fact is communicated to the universe through the uParameter with index VIEWSIZE.
Methods related to Security
The section contains methods intended to insure that the executing processor is not brought to its knees by mistake
or evil intent. The methods ensure, for example, that only one copy of a universe can be running at any time and
that cloning or other duplication is prohibited.
A Summary of Java as used for a Rart Universe
The definition of a universe should be relatively stable over time to ensure that the work of art created also
lasts and remains executable. We repeat here what we said above that we deliberately have selected an early Java
version for the universes and removed the need for the programming of the user interface as well as the need for
dealing with threads, exception handling, and input-output. A beginning student can for this reason concentrate
on syntax and the handling of graphics. My experience is also that it helps that almost all numeric variables are
either integers or, only occasionally, long integer.
The function of a rartrunner is to service the universe and effectively isolate the universe from an operating
environment that may vary over time and with the introduction of new Java features. The rartrunners can for this
reason provide whatever the current Java environment supports and may be modified to use new Java features that
would make the life of the universe observer more pleasurable.
The Rart runtime environment in RDK 2.0 is provided in three packages, rartbase,
rrlet, and rr11. The package rartbase is always needed, the package
rrlet is needed to execute a universe in an applet, and rr11
is needed in addition to execute a universe in an appllication in a JDK 1.1 environment. We shall briefly describe
the functions of these packages.
Simple Applet
The package rartbase contains among others the classes: RR and RRL
as well as Universe as we have seen above and the uParameter
class which provides the uParameter functionality.
RR is the basic rartrunner with very limited capabilities. It does, however,
allow the execution of a universe as an applet. The declaration of RR reads:
public class RR extends Applet implements Runnable{ // . . . }
This rartrunner needs to be an applet in order to execute universes over the Internet. RR can, in fact,
be used to start a universe, say MyUniverse, with the following applet
tag:
<APPLET CODE="rartbase.RR.class" WIDTH="760" HEIGHT="450">
<PARAM NAME="UNIVERSE" VALUE="MyUniverse">
<PARAM NAME="DEBUG_LEVEL" VALUE="2">
</APPLET>
RR allows the parameters WIDTH, HEIGHT, UNIVERSE, and DEBUG_LEVEL,
where UNIVERSE provides the (Java class-) name of the universe and DEBUG_LEVEL is used to turn on and off up to five levels of debugging output
during development. What RR does not do is deal with parameters (except for any change of window size, which is
handled through the uParameter with index VIEWSIZE). This means that the
universe will execute with default values that cannot be modified. RR does, however, deal with resources, at least
images and text. Sound files are trickier and are not yet handled correctly as of January 2003. RR also supports
the "About" dialog which presents the rartist provided information
about the universe and is activated through a "long" ( longer than 500 ms) mouse click.
RRL, which stands for RartRunner Light, is intended for the display of
universes in a fixed environment such as a web page. RRL extends RR and adds two methods, getHTMLuParameters()
and doubleClick().
The first method is used to access values provided in the applet tag. If, for example, the uParameter with index
NUMBER is defined for the universe it can be given a value by the addition of the line <PARAM
NAME="NUMBER" VALUE="22"> in the applet tag suggested above. This gives the uParameter
the value 22, if 22 is in the range defined for the uParameter. If the value is outside the range, it defaults
to the maximum or minimum value of the range if the value is greater or smaller, respectively. So for RRL,
the way to execute the universe with different values for the parameters, is to edit the startup html document
and restart the universe with uParameter values as desired, also of course, invoking CODE="rartbase.RRL.class"
However, we have decided to allow one uParameter to be modified by the observer. This is done through the doubleClick method, but only for the uParameter with index NUMBER. When the
user double clicks the applet, the uParameter is modified such that one tenth of the permitted range is added to
the current value modulo the upper range. This has the effect of cycling the allowed range of values in ten steps.
A complete Applet
The package rrlet adds the classes that allow full deployment over the
Internet. The class RRlet is the rartrunner, and RRlet
extends RRL. The package also contains classes to handle the various dialogs.
A long click invokes the "Select Action" dialog which allows the observer to select among a number of
actions, one of which is "Change Parameter." This leads to another dialog box listing the names of the
parameters of the universe. When an observer selects one, a final dialog box appears with the rartist provided
description and a means to modify the current value of the uParameter. For the first type of uParameter, the observer
drags a scrollbar, for the second type he/she selects from a list of alternatives. This may all seem somewhat awkward,
but it is to be noted that the RRlet rartrunner has been programmed in
Java 1.0 2. It can thus with minor modifications to RR be used with really old browsers.
The rrlet package also contains a specialized and customizable rartrunner
rrletDemo, which is used to display continuously running predefined universes
selected at random in the environment of a demonstration. rrletDemo extends rrlet and adds facilities to interrupt
the execution and includes hard coded lists of universes to be executed.
A complete Application
The package rr11 includes the remaining classes to allow the execution
of a universe in an application environment. The rartrunner is called RR11
since it really required the functionality of Java 1.1 to be operational. It extends RRlet
and adds a number of fairly large and complex classes.
In order to provide the ability to select from among available universes each universe comes with a short file
with the same (Java) name as the universe, but the extension .unv. Possible
future uses of the unv file for security and authentication is beyond
the scope of this paper.
RR11 starts up a banner from which the observer escapes through a long
click that invokes a file selection box. In the file selection box, a list of the files with unv extensions appears.
Once a universe is selected, it starts up using default values for any parameters. It is in the application case
not possible to provide non default values on the command line except for WIDTH, HEIGTH, UNIVERSE and DEBUG_LEVEL.
The option to select another universe for execution through the same file dialog is available once the rartrunner
gets started, and the modification of any parameters is also simple.
The user interface is now a multilevel popup menu activated with a long mouse click. The options lead to the same
parameter change dialog as in the RRlet, but the convenience is much improved. Two more options are introduced.
By selecting "Freeze" the observer can freeze and
save up to five views of the universe, that is, moments of particular beauty or other interest. The "Print" option allows the observer to select from any of the recently
saved views of the currently running universe. The selected view can be printed out after the observer has added
a title. The printout can be in either landscape or portrait format. In the portrait format, the view is scaled
to fit on half the paper making it suitable for mailing as a postcard. In addition to an optional two-line title
(or dedication and title) the printout provides a border as well as a timestamp with the moment of selection.
The Effects of a Flexible Execution Environment
We have seen how the rartrunners isolate the universe from its executing environment. It is of no concern to the
rartist how or where the universe is executed. A further and in the long run more important benefit is that the
rartunners can evolve with time to take advantage of new Java features as well as new or evolving operating systems.
This provides the assurance that any universe will remain executable over time as well as across any present or
future platforms with no further effort on part of the rartist. A Rart universe will exist as long as computers
are used on Earth.