JTF > Rationale > Introduction

Chapter 1
Introduction


Since its introduction in 1995, Java has created quite a buzz in the computer science education community. If you look, for example, at the names of programming languages appearing in the titles of papers accepted for the SIGCSE annual symposium over the past eight years, references to Java outnumber those of all other programming languages combined. The trend toward the use of Java as the language for introductory computer science courses was evident as early as 1998 [Stevenson98] and has since gathered additional momentum, bolstered in part by the decision of the College Board to move the Advanced Placement Computer Science program to Java in the 2003-04 academic year [Astrachan00]. Some authors have suggested that Java has achieved a position of prominence within the academic community similar to that of Pascal in the 1980s, arguing that “we should shift our attention from the whether Java question to the if Java, then how question.” [Wallace97]

Despite the fact that an increasing number of institutions are moving to adopt Java in their introductory curriculum, those institutions do not by any means report universal satisfaction with Java as a teaching language. The problems that arise in using Java at the introductory level were analyzed in more detail in a paper by Eric Roberts at SIGCSE 2004 [Roberts04a], which concluded that the observed difficulties in teaching Java are representative of a more general challenge facing computer science education. At its essence, that challenge arises from two self-reinforcing characteristics of modern programming languages that have a profoundly negative effect on pedagogy:

To address the problems involved in using Java at the introductory level, the ACM Education Board initiated the ACM Java Task Force in early 2004 with the following general 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. [Roberts04b]

This document represents the final report on the rationale behind the Task Force decisions. Two earlier drafts were released for public comment; the first draft appeared in February 2005 and the second in February 2006. The purpose of this document is to describe the design decisions we made and the reasons that underlie those decisions. Chapter 2 outlines the principles adopted by the Task Force along with a summary of how we have carried out our work. Chapter 3 goes on to present a detailed analysis of the problems that face teachers who use Java at the introductory level.

The general taxonomy of problems from Chapter 3 revealed four significant challenges that instructors face teaching Java, along with several smaller ones. Those four challenges, shown here with their identifying labels from the taxonomy, are as follows:

   L1.Static methods, including main
   A1.Lack of a simple input mechanism
   A2.Conceptual difficulty of the graphics model
   A3.GUI components inappropriate for beginners

To provide some help in reducing the many difficulties associated with problem L1 (Static methods, including main), the Task Force has developed the acm.program package. This package defines a hierarchy of program classes that simplify the creation of programs and encourage students to work in an object-based environment rather than a static environment. The package, moreover, makes it possible to unify the concepts of applets and applications and provides support to application writers that is ordinarily not available. Because the description of the acm.program package depends on several of the other proposed packages, the detailed discussion of acm.program appears in Chapter 6, following the descriptions of the packages on which it depends.

Our approach to addressing problem A1 (Lack of a simple input mechanism) is to produce an acm.io package that offers two principal classes: an IOConsole class that offers simple input/output operations in the context of a traditional line-oriented console and an IODialog class that implements these operations using a popup dialog. These two share a common interface, which makes it easy to substitute one model for the other. The acm.io package is described in detail in Chapter 4.

Problem A2 (Conceptual difficulty of the graphics model) represents the area in which we invested the greatest part of our effort. We examined several models suggested by members of the computer science education community [Bruce04a, Parlante04a, SandersK04a] and used those as models for an acm.graphics package that combines the best features of each. The acm.graphics package is covered in Chapter 5.

As of the first draft of this rationale document, the Task Force had chosen not to propose a new package to address problem A3 (GUI components inappropriate for beginners). The feedback we received over the next few months, however, made it clear that we needed to try harder to come up with a solution. The community clearly identified the difficulty of building graphical user interfaces (GUIs) to be a significant barrier to the effective use of Java in introductory courses. The Task Force continued its deliberation and reviewed in more detail several of the proposed solution strategies [Lambert04a, SandersD04b, Rasala04a]. The product of that review was a new acm.gui package described in Chapter 7 along with a set of useful extensions to the Program class described in section 6.5.

The feedback we received on our initial proposal led to yet another change in the design of the various ACM packages. In the first public draft of this rationale document, the Task Force had coded the library packages so as to maintain compatibility with Java versions extending all the way back to release 1.1 of the Java Development Kit (JDK), which appeared in April 1997. The purpose of that decision was to ensure that programs built using the Task Force libraries could run in old browsers, including most of those currently deployed at commercial Internet-access sites. Even though that decision in no way limited the features that adopters might themselves choose to use when building applications on top of our packages, the choice made those packages appear obsolete and was all too often criticized on that basis. In part to forestall that criticism—and in part because the acm.gui package made it more difficult to continue with our original strategy—the new versions of the Task Force packages use JDK 1.4 as their foundation. The reasons behind that decision and the strategies we now use for maintaining compatibility with older browsers are described in Chapter 9, which also identifies the subset of Java classes that the Task Force recommends for use with the ACM packages.


Final Report—July 31, 2006