University of Virginia, Department of Computer Science
CS655: Programming Languages
Spring 2000

Position Paper 0
David Larochelle
24 January 1999

The Declaration of Independence from Java

We hold these truths to be self evident that all computers are created equal, endowed by their creators with the ability to perform certain tasks, among these is the ability to simulate a Turing machine. That to facilitate directing computers in these tasks, programming languages are instituted by programmers. When programming languages no longer help programmers, it is the right of programs to alter them or create new programming languages more appropriate to the problems at hand. Prudence, indeed, will dictate that programming languages long established should not be changed for light and transient causes; and accordingly all experience hath shown, that programmers are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the programming languages to which they are accustomed.

When a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to it is their right, it is their duty, to throw off such a programming language, and to provide new Guards for their future programs. Such has been the patient sufferance of Java programmer; and such is now the necessity which may constrain them to alter their former programming language. To prove this, let Facts be submitted to a candid world.

Java fails to provide a consistent interface. The APIs change constantly. The changes are often minor. For example, the recent spec changed the method for adding an element to a vector from addElement to add. Large scale changes occur as well. The event handling model in version 1.0 is completely different than 1.1. The problem is not any individual change but the cumulative effects. If old methods are removed, then backwards compatibility is lost. Maintainability suffers because programmers unfamiliar with old methods can't understand old code. Maintaining old interfaces decreases readability. There are two methods that do exactly the same thing. In either case, those who have learned Java must relearn it.

Java requires the use of object oriented programming but fails to provide standard constructs and protections. Neither operator overloading nor templates are supported. Java's poor substitute for templates, casts to Object, violates the concept of strong type checking which the language claims to embrace. There is no way to do compile time type checking on code that casts to and from Object. Java compiles the following code without a whimper:
Vector v = new Vector(); v.add("HEllo"); Integer x = (Integer)v.firstElement();
Adding different types to the same vector is perfectly legal. Java forces us to rely on run time errors to detect problems like this. But run time testing is notoriously difficult.

Many languages provide optional ways around safety feature. Casting to Object is dangerous it is the only method for accessing the provided data structures. Work arounds such wrappering Java language classes, remove the advantage of a standardized library. Readability is decreased because we now have to determine what the wrapper class does.

Java provides an extensive library, but lacks a number of basic routines found in nearly every other languages.

Java lacks reasonable text IO routines. The included routines only allow you to read and write strings. Variables must be converted to strings before they can be printed. Input must be read in as a string then parsed and converted to the appropriate format. The lack of simple text IO routines to handle these chores greatly complicates IO intensive programs.

Another glaring omition is the lack of semaphores. The Synchronize construct does not eliminate the need for semaphore. Programmers must resort to busy waiting or break up all sections that may be contending for a resource into separate functions and synchronize each one. The former is inefficient. The latter results in ugly and convoluted code.

Java lacks reasonable debugging support. Part of the problem is implementation related. There is no easy way to get information on a dead process. Java lacks a core or equivalent facility. This is a problem but one that could be fixed without changing the language. Java uses exceptions as the exclusive method of error handling. Exceptions can be particularly hard to track down. Unless the programmer is willing to include numerous redundant try catch blocks the causes of exceptions are difficult to find. Often the programmers would simply like to get full information on every exception. Unfortunately to do this would require try catch blocks around every statement. Some simple changes to error handling would greatly simplify debugging.

Given Sun's propensity to make changes to the language, we hope that Sun will implement some of these changes. Many of these changes could be implemented in such a way that they don't break existing code. Although the constant changes to the API's are a flaw in the language they may allow this sort of change. Otherwise programmers will indeed be forced to find another language.

References

I took much of the style of this paper from the Declaration of Independence by Thomas Jefferson.

I used the Declaration of Independence as posted by David Evans who used the the web transcription from the National Archives.

Collaborators

Nothing significant. I wrote the basic outline over the weekend. I was working on stylistic changes before I have a chance to talk with anyone, and did want to rework the paper.


CS 655 University of Virginia
CS 655: Programming Languages
drl7x@cs.virginia.edu
Last modified: Tue Jan 24 11:10:50 2000