Impressions of SD '98

A programmer's perspective on the recent Software Developer Conference in San Francisco

For three days in February, I roamed the halls of the Software Developer conference at Moscone Convention Center in San Francisco. I attended the sessions of the Java track and served as a judge at the Java Superbowl. In this article I share with you some of the insights I gained through these experiences.

Rock music, lights, and spin

Having attended both JavaOne conferences (in '96 and '97) and having never before attended the sessions at the Software Developer conference, I am naturally inclined to draw some comparisons between SD and JavaOne.

At the first JavaOne in '96, the atmosphere was filled with raw excitement. Everyone was walking around rather stunned by the new technology, and excited about its future prospects. The feeling at the second JavaOne in '97 did not quite achieve the level set in '96 but nonetheless was a lot more exciting than this year's Software Developer conference. Compared to JavaOne, SD is quite subdued, in part because Sun really plays up JavaOne with lots of fancy decorations, light shows, and rock music.

Although the excitement of JavaOne is fun to experience, you have to bear in mind that JavaOne is basically a three-day infomercial for Sun and JavaSoft. At JavaOne, you get great information, but you also get Sun's spin on that information.

At last year's SD, Bill Gates gave a speech about Java. Although I didn't attend SD's sessions last year, I did attend Bill's speech. Last year's SD coincided with JavaOne (they were in opposite wings of Moscone Convention Center in San Francisco), so last year I got Microsoft's spin on Java at SD while I got Sun's spin at JavaOne. Knowing what I knew about Java technology, I felt that compared to Sun's spin, Microsoft's spin had far greater angular velocity.

At this year's SD, however, Bill Gates did not appear, and the Java information at the sessions I attended was for the most part spin-neutral. At SD, they give it to you fairly straight, to equip you with the knowledge you need to decide when and how to apply Java in your work.

The one glaring exception to the "SD is subdued rule," is SD's Java Superbowl, where the attendees let out all that pent-up energy. More on the Superbowl later. First, I'd like to describe some highlights of the sessions I attended.

The Java virtual machine

Those of you who have read my former JavaWorld column, Under the Hood, or my book, Inside the Java Virtual Machine, may have guessed that I am rather interested in Java internals. It's true, and in pursuit of this interest I attended two sessions presented by Allen Holub that focused on the Java virtual machine (JVM).

At these sessions, I discovered that Allen and I share similar research interests. I also discovered that we share similar subject titles. Both the title of Allen's presentation, "Inside the Java VM," and the title of his current book project, Java Under the Hood, sounded quite familiar to me!

I enjoyed Allen's JVM sessions immensely. His broad overview of Java internals was composed of the kind of information everyday Java programmers would want to know.

Why the stack, James?

In one portion of Allen Holub's presentation that I found especially interesting, he described optimization techniques used by just-in-time (JIT) compilers. In his presentation, Allen hit on something important that was also mentioned by James Gosling in his Software Development '98 keynote: a major motivation for the stack-based architecture of the JVM's instruction set. As Allen put it:

Every compiler in the world uses a stack-based architecture to pass intermediate compiled form to an optimizer.

This is a key insight. In Java's architecture, the Java compiler does not usually perform much optimization -- it leaves most of it to the JVM. The stack-based architecture of the JVM's instruction set enables just-in-time compilers to easily build an abstract syntax tree and perform optimizations as they convert bytecodes to native machine code.

For links to more information about the JVM or Allen's presentation, see the Resources section at the bottom of this article.

Java design

Besides the JVM, my other focus at SD was design. I attended several design-related sessions:

  • Kenneth Pugh's "Judging Java programming idioms"
  • Peter Coad's "Building better applications with composition and interfaces"
  • Allen Holub's "Implementing model/view/controller using the JDK 1.1"
  • Bruce Eckel's "Using design patterns with Java"
  • Larry O'Brien's "Design patterns and real-time simulations in Java," parts I and II


Design patterns figured heavily in SD's Java track. Design patterns are an approach to design in which common design problems are identified and the solutions to those problems are described and named. Four of the sessions I attended dealt directly with design patterns.

Allen Holub presented an in-depth example of the Model/Controller/View architecture, a design pattern that shows one way to organize programs that have graphical user interfaces. This is an important architecture for Java programmers to get to know, as the new Swing GUI classes of the JFC library are organized with M/C/V in mind.

Bruce Eckel walked us through "Using Design Patterns with Java," Chapter 16 of his book Thinking in Java. In his talk, Bruce led the audience through several iterations of applying patterns to the design of an object that sorts trash.

Larry O'Brien gave two sessions of material on architectural and design patterns. Whereas the term "design patterns" usually refers to patterns that talk about objects, the term "architectural patterns" refers to patterns that talk about the components of a system. So a design pattern might help you design the interaction between objects within a single process. An architectural pattern might help you design the interaction between several processes that make up your complete system.

One point emphasized by all these presenters was that patterns establish a common vocabulary for discussing design. As Larry O'Brien put it:

The major advantage of patterns is they let you talk about design.

If you haven't already, you should probably start learning about design patterns. You don't want to be left out of the conversation, do you?

For links to more information about design patterns, see the Resources section at the bottom of this article.

...And idioms

The design session that I enjoyed the most dealt not with patterns, but with idioms. Kenneth Pugh's session, "Judging Java Programming Idioms," was quite useful and entertaining. In it he showed several ways to solve various design problems, and then asked the audience to comment on his solutions and vote for the one they preferred.

What I really liked about this session was its interactive flavor. On the topic of design, letting the audience debate with one another and then vote for the "best" solution made a lot of sense to me.

Why do I think interactivity is useful when talking about design? Because the people who will have to decipher your code and live with your design and coding decisions are your programming peers. Thus, the development of design and coding guidelines should be guided by a discussion among the programmers who have to work with each other's code. It should not be an edict passed down by some so-called guru. (This is, incidentally, why I encourage feedback on my Design Techniques articles and my current book-in-progress, Flexible Java. I hope to make the column and related book project a guided discussion about Java design.)

Set/Get: Thumbs up

Among many other issues, Kenneth Pugh's session questioned the merits of the following three approaches to designing and naming methods:


Many of you may recognize the first column as methods of class java.awt.Component that were deprecated in JDK 1.1 in favor of the method in the third column. In this act of deprecation, methods show() and hide(), which represent services, were dropped in favor of method setVisible(boolean), which manipulates an attribute.

One motivation behind using set and get methods is that JavaBeans tools use them to manipulate bean attributes. But what if you are designing a class that isn't destined to be a bean?

In the discussion of this set/get issue, the session audience debated whether option I or option III was better. (Nobody liked option II.) Although I felt that the audience couldn't clearly articulate why it preferred one approach over the other, when it voted it was clear: The audience heavily favored the set/get approach of column three.

Set/Get: Thumbs down

At the beginning of Allen Holub's Model/Controller/View talk, however, Allen made it clear that he was against attribute-centered approaches to method design, such as set/get, and he articulated a coherent philosophy to support his view.

Allen started by saying that objects weren't originally conceived as bundles of data and the code that knows how to access the data, but instead were conceived as bundles of services. He said that although most objects would have state (variables that represent attributes) to help them perform the services they offer, the primary external view of an object should be its services.

Allen identified set/get methods as one example of the "viewing objects as data/code bundles" syndrome. He suggested we try to think in terms of services, rather than attributes. As an example, he said that rather than asking a BankAccount object for someone's balance, you should ask the object whether it is okay to withdraw the amount the account owner is requesting. So, instead of calling a method such as getBalance(), you would call a method such as okToWidthdraw(int amount).

To quote Allen:

Get and set methods are evil.

Allen's basic philosophy was that you should ask the object that has the necessary data to do the work for you. Instead of getting a balance from a BankAccount object and then comparing it with a requested withdrawal amount, for example, you would pass the requested withdrawal amount to the object and let the object that already knows the balance do the compare.

For more information on design idioms, see the Resources section. If you have an opinion on the Set/Get issue that you are dying to express, the Resources section contains a link to a discussion forum where you can let the world know what you think.

The Superbowl

Aside from attending sessions and wandering around the booths at the Pavilion, I participated in one other attraction sponsored by Software Developer '98: the Java Superbowl. For the second year in a row, I was privileged to have a front-row seat as a judge. To my left and right were nine other judges. In front of me on the stage were five teams of two programmers each. Behind me were about 1,000 restless Superbowl fans.

The Java Superbowl is a contest between vendors of Java interactive development environments (IDEs). This year, five Java IDE vendors fielded teams: Borland, Sun, Supercede, Sybase, and Symantec. Each team of two programmers was given identical hardware, a 200MHz Pentium workstation running their choice of either Windows 95 or Windows NT, but each team used different software. On each team's workstation, the Superbowl officials installed that team's own IDE development tool and any libraries that normally come with the tool.

Every team was given an identical list of problems, where each problem was a description of a Java applet or application and associated point values. Most problems had multiple parts, with each part building on the previous part, and with each part carrying its own point value.

For example, here is one problem from this year's list:

Swimming Fish Applet

Using threads, create a swimming fish applet. Use an oval for the body, a small dark circle for the eye, and a triangle for the tail. Make it move slowly across a panel, starting over again when it swims off the other side.

Possible Points: 100

Bonus Points: 50, for making the tail wiggle

The teams chose problems from the list and when the Master of Ceremonies said "go," the teams began coding using their own company's IDE. While the teams worked, the contents of their workstation monitors were projected onto giant screens that hung above the stage, enabling the audience see how each team used its IDE tool. From time to time during the contest, marketing people from the competing vendors were allowed to throw promotional T-shirts into the audience.

After about 45 minutes of frenzied coding, the teams stopped working and gave demos of the programs they had completed. Based on these demos, the judges awarded points. After the demos, the judges' points were tallied and combined. The team with the most points was declared the winner.

At this year's Superbowl, the team from Borland won first place, with the team from Symantec coming in a very close second.

The right stuff

Although on the surface the Superbowl may appear to be a contest between development tools, in reality many factors play a role in determining a winner. The development tool is certainly part of the equation, but there are other important factors, including:

  • The team's familiarity with the tool
  • The depth and breadth of the team's programming and Java expertise
  • The team's ability to work quickly and under pressure
  • The problems the team chooses to attempt to solve
1 2 Page 1
Page 1 of 2