Dilip Barman, Saturday, December 13, 1997

1) [40%] Essay re: Java as a language (1-2 pages)

Java is not just another programming language. It includes features that could lead to fundamental changes in the ways in which we think about and use computers.

By some measures, java is "yet another programming language" with quite a number of good features. It is object-oriented, so supports encapsulation and encourages rapid development through reuse. It builds on existing knowledge many programmers have of (C and) C++ and includes some strong points of languages like Smalltalk, such as more pure object orientation (almost everything except base types are objects in java). It improves on well known pitfalls in languages like C++ through simplifying notions like pointers and array accesses, and avoids the complexity of multiple inheritance in languages like Smalltalk by adopting single inheritance (with allowance for overriding interface methods). It supports a simple model for many key paradigms in modern computing such as event-driven programming, client-server communications, graphical user interface creation, and asynchronous processes. It has improved security considerations by restricting file accesses, and its open architecture encourages finding and fixing of subtle security problems.

However, I have to largely agree with the thesis posited in the question that java is more than just another language. It's biggest boon is the theoretical ability to be written once and run everywhere. Platform independence through byte codes and virtual machine interpreters is not a new goal but earlier efforts (I remember the Pascal UCSD-p system that compiled to an intermediate and portable byte code) never seemed to catch on, perhaps because they weren't attempted for languages meant to be used in production. java is the first instance of a reasonably widespread, reasonably platform-independent language. This allows for new ways of distributing code.

One of the biggest problems in contemporary information systems is configuration management of maintaining user desktops and application suites. How can we be sure all users in an enterprise are using versions of programs with the features that they need, how can we keep software upgraded, and how can we ensure that the various software environments that users have can inter-communicate? While moving from monolithic mainframes with dumb terminals to smart, independent workstations that use mainframes for communications and data access is largely an exciting move, it also burdens knowledge workers to become system administrators.

The write-once run-everywhere philosophy makes it feasible to start looking at other ways of delivering software applications and working environments. Users can be given access to common code bases that are maintained (as traditionally had been done) centrally and simply pick up java classes as needed. (Ironically, this is akin to a move back to the monolithic server, but with smart client computers doing much of the data processing locally.) Whole work environments can be downloaded to give enterprise users a consistent and supported milieu. This is particularly appealing within organizations with high speed LAN access, but as the internet bandwidth problem gets better (through investment and infrastructure from cable and/or telephone companies, for example, as well as possible government support), becomes more appealing for mobile and home computer users.

This paradigm shift away from buying off-the-shelf software to dynamically getting functionality that one needs has a lot of implications. As internet-based "eCommerce" is more established, users can be charged a per-usage fee for programs that they need. Instead of spending $200 on an office suite, a user might have a fraction of a penny deducted every time s/he uses a word processor or appointment scheduler. Especially if network stations (really moving back to dumb terminals!) take off to any extent (I personally doubt they will ever reach more than 10-20% of installed computers, but even that is a sizable market opportunity), new businesses will spring up to handle storing the data used by those downloaded java applications. A user might use the services of (and implicitly pay) a tool vendor as well as a data storage vendor in doing common tasks. Furthermore, new vendors will provide substitute interchangable parts to applications. Even enterprise users, where consistency is important, may be able to interoperate with visually different environments that even have apparently different functionality at the user interface level.

Another aspect of java that may lead to new computing paradigms is its wide acceptance and small footprint that gives it the easy ability to be bundled into consumer devices. The language, afterall, had such design goals early on. The idea is that the java virtual machine can be run in a small address space and can easily be run off of silicon. I believe that already there are efforts underway to create "smart" devices with java interpreter chips built in.

This ushers in a much more ubiquitous form of computing with our everyday appliances and tools being our very natural user interfaces. One can envision televisions delivering customized programs on-demand (when I turn the TV on at 3a, the TV "knows" that I missed Newshour with Jim Lehrer and broadcasts it - possibly from where I stopped watching - along with any news updates); smart houses with houselights turning themselves on and off in a realistic manner to give the appearance of a lived-in house when we're away or to expect our return, and heating and air conditioning tuned to our lifestyles and comforts; and our camcorders downloading images from our grandchildren and other family. I know this paragraph is a bit fanciful, but a language like java that can be easily realized in silicon compactly (for given class libraries needed in a device) makes smart devices more realistic.

One challenge that I think java might have before achieving these science fiction-like ideals is true simplicity and consistency across platforms. Visual development environments that move developers away from a 1960s and older era view of coding on a file basis to one based on class instantiation and subclassing by an intuitive GUI that is environment and not file based (e.g., the Smalltalk environment), as well as provide tools to support OO design, code factoring, etc. are needed. Finally, the dream of true write-once run-everywhere needs to be borne out in reality.

2) [60%] Java concepts, brief (up to 6-8 stmts) illustrative code

– frame

When you execute java statements in an applet or application, they take place in the context of either a panel or a frame. A frame is a subclass of the java Window class, and is not dependent on the outer calling context. It can listen for and respond to window events, like move and close, and has its own border and title. The following code snippet displays a red frame with a window title and some buttons.

Frame myFrame;

Panel myPanel;

myFrame = new Frame("Window title");

myPanel = new Panel;

// We define buttons and other UI widgets separately

myPanel.add (myFirstButton);

myPanel.add (mySecondButton);

myFrame.setBackground (ColorRed); // syntax?

myFrame.add (myPanel);

myFrame.show; // display the frame

– layout manager

A layout manager gives one control as to how UI components are added to a context like a panel or frame. Some layout managers specify that components are added left-to-right and top-to-bottom in a stream-like manner (FlowLayout, I think); others (BorderLayout) work well where the heuristic of maximizing a central area is important, and focus on adding components to top ("North"), bottom ("South"), left ("West"), and right ("East") sides, as well as a main central (I've forgotten - "Center"?) area. There are about six layout managers in java (a few others are CardLayout, GridLayout, and GridBagLayout), and one can define one's own layout manager. In addition to defining the layout, layout managers define how constituent components move upon resize events. The code below defines a frame with a large central blue panel and two buttons near the bottom.

// Define frame, buttons, and 2 panels

myFrame = new Frame("Window title");

buttonPanel = new Panel; actionPanel = new Panel;

startButton = new Button ("Start the Action!");

stopButton = new Button ("Stop, Please");

// Arrange buttons on bottom and main action panel

buttonPanel.add (startButton);

buttonPanel.add (stopButton);

actionPanel.setBackground (ColorBlue); // color panel

// Above was default flow layout

myFrame.addLayoutManager (new BorderLayout());

myFrame.add ("South", buttonPanel);

myFrame.add ("Center", actionPanel;


– event

Event-driven programming is key to writing programs that react to user actions, like mouse clicks and motion, window resizes and moves, and general GUI interactions. An event is any such activity that the java virtual machine can capture. The java 1.1 event model allows classes to register to listen on events and classes to implement methods to handle these events. The code snippet here allows the class MyClass to handle action events as it "implements ActionListener", and registers a UI button to listen on events (e.g., when it is pushed); here we simply say the listening is handled in this same class ("this"), but it could be in another class.

MyClass implements ActionListener

{ ...

addButton.addListener (this);

public void ActionListener (Event someEvent)

{ if (someEvent == addButton) { // code to handle this }

else if (someEvent == showButton) {// handle "show"}



– thread

A thread is a lightweight process. Threads of control typically work together or in parallel, but don't require the operating system to allocate separate address spaces, contexts, etc. Threads are useful for asynchronous tasks that may have to periodically synchronize with each other. In java, threads can be implemented by a class implementing the Runnable interface or by extending the java Thread class. A run() method must be defined that is executed when the thread is given control. In addition, start(), stop(), and I think destroy() methods define what happens when the thread is, respectively, resumed, paused, and killed. The first snippet of code below is the definition of a class MyThread which defines the Runnable interface. As is typicaly, when the thread is run, it is in an infinite loop, waiting for an exception or for a thread.stop or thread.destroy (I think I'm right about its being called "destroy", but it could be something like "quit"?) message. In another class, we have the three statements following, which instantiates that class and runs two threads of control.

MyThread implements Runnable


public void run() { while (true) { ... } }

public void stop() { ... }

public void start() { ... }

public void quit() { ... }


animationObject = new MyThread;

refereeObject = new MyThread;

animationObject.run(); refereeObject.run();

– client

Client-Server computing is a now well-established computing paradigm. The idea is that a server process (e.g., a computer with a database) waits for requests from clients (e.g., a program handling an end-user request for information from the database) that can communicate with it via inter-process communications or over a network. The server waits on a well known port (if using TCP/IP) and when it detects that it is being summoned, it responds to client requests. The best known example of a client-server system is the Worldwide Web with httpd servers and browser clients. Client-Server computing is particularly easy in java, and classes like java.net and java.io allow with only a few statements for clients and servers to operate. I am a bit shaky on the exact syntax, but basically client code defines a connection to a computer and a port on that computer, and then sends stream data (using writeutf I believe; this writes unicode so that computers with different natural languages (and therefore potentially double byte character representations) can handle sent strings:

Socket connection;

URL destinationHost;

// Define destination host - something like next line?

destinationHost = new URL ("ashe.cs.unc.edu");

connection = new Socket (destinationHost, 1901);

writeutf ("message from client", connection);

– server

The foil to the client is the server. As described above, the best known example of servers are web servers (httpd daemons for unix machines) which wait on requests from Netscape, Internet Explorer, Mosaic, and other web clients, and handle http requests by serving up web pages and interfacing to cgi programs. Again, my syntax and specifics are surely off, but the java code is quite easy to implement a server (especially easy if you have access to reference materials such as the java class libraries javadoc documentation!). Below, we simply wait till there is a request on port 1901 (defined as static - class variable - final - constant), then we accept a connection:

// Define socket where I'll listen

ServerSocket mySocket;

static final Int myPort = 1901;

// Define connection for incoming requests

Socket connection;

mySocket = new ServerSocket (myPort);

// All we do is hang out and wait for connections

connection = mySocket.accept();

3) Children`s Games Suite java project

Arianne Belcourt: She was really on top of things and actually got her part of the project done a few weeks early! She was conscientious, hard working, and her part of the project worked nicely. I'd assign her 40 points.

Elizabeth Robbins: The project idea was hers. She was creative and put a lot of time into her portion of the project. I would give her 30 points.

Me: I enjoyed working on the project (most of the time!) and put a lot of time into it. I was not able to get started on it till late in the semester, and wish I had an extra week. I would give myself 30 points.

Pledge: I have neither given nor received unauthorized aid on this exam. (I did the exam at home without consulting any reference materials, and worked on it Saturday 12/13/97 from about 2:45p-5:15p.)

... but I wish it were at least an open-code exam, so I could check my syntax! I am glad we could type this; I can write much more effectively on my keyboard vs. handwriting. Thanks for an interesting and useful course, and particularly for setting all course artifacts up on the web - that will serve as an excellent reference for myself and for anybody who wants to learn perl and java.