Impressions of SD ’98

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

Patterns

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

My observation has been that one of the most critical factors for success in the Superbowl is choosing the right problems to attack. If you want to win the Superbowl, what you have to do is know your IDE, know your Java, and attack the weakest part of the problem list.

The true meaning of the Superbowl

The one thing, however, that has really jumped out at me about the Superbowl is the ability of the T-shirt prize to bring computer programmers out of their shells.

Computer people have a reputation for being introverted, and at one of the sessions, I observed some behavior that seemed to fit this stereotype. As I entered the room for Peter Coad’s talk on Java Design, I was handed a cool toy. Peter was giving away brightly colored whistles — plastic cylinders about 5 centimeters long and 1.5 centimeters in diameter. Inside the cylinder was a turbine-like mechanism that rotated as you blew. As the turbine increased in speed, the pitch of the whistle went up. It was really cool.

About a hundred people were waiting in the room for the session to begin. As I sat staring at my whistle, which rested on the desk in front of me, it occurred to me that Peter Coad probably wanted to warm us up with these whistles. I turned to the guy next to me and said, “You know, I think it says something about the personality of software people that not a single person in this room has blown on their whistle even though we’ve been sitting here ten minutes.” This comment must have gone to work on some deep part of the psyche of the fellow sitting next to me, because after about a minute he picked up his whistle and blew.

Now you would expect this initial whistle to break the ice, to let the others know it was okay to make a little noise with these whistles. But my compatriot’s whistle was met with silence. No one in front of us even turned around to see who the transgressor was. I think they all felt uncomfortable. But then approximately a minute later, just as I was about to give up, there was a feeble whistle reply from the back corner of the room. That, however, was the extent of the pandemonium Peter Coad generated by passing out the whistles.

At the Java Superbowl, on the other hand, I observed behavior that belied the introvert stereotype. My conclusion is that you’ve just got to give these people the right bait, and they’ll go wild. Cool plastic whistles weren’t effective, perhaps in part because everyone was studying them trying to figure out how the turbine worked. But the people who run the Superbowl know the secret. It’s free T-shirts, or, more specifically: free T-shirts flying through the air!

From time to time during the competition, as the teams worked to build their Java apps and applets, master of ceremonies Richard Hale-Shaw gave the command. The media people cranked up the rock music. Marketing people from each competing vendor grabbed the T-shirts they brought and ran toward the audience. And for the next ten seconds, promotional T-shirts from Borland, Sun, Supercede, Sybase, and Symantec filled the air.

The T-shirts arced high above the crowd, paused teasingly in the air, then began their descent. And what did the introverted programmers in the audience do? They went absolutely nuts.

People jumped out of their seats. They yelled. They waved their arms. And when a T-shirt happened to come in their direction, they leapt into the air trying desperately to pluck the T-shirt out of the sky before their neighbor got it.

So I have come to the conclusion that the true purpose of the Java Superbowl is not development tools, or programming prowess, or the ability to perform under pressure. It’s T-shirts.

I think the flying T-shirts are a form of therapy. For a few frenzied moments, the T-shirts enable 1,000 mild-mannered computer programmers to cast away their introverted shells and go crazy.

Go for it

If you attended Peter Coad’s session and now regret that you didn’t have the gumption to blow on that whistle, don’t worry. It’s not too late. As a first step, press on the button below (a Java applet) to hear a recording of one of those cool turbine whistles in action.

Download the source code for the Whistle applet.

Conclusion

The Software Developer conference gives it to you straight. At SD, they keep the hype at the product booths in the pavilion, the rock music and light shows in the Java Superbowl, and in the sessions, they simply give you practical information free, for the most part, of marketing spin.