Much is made of the fact that Java syntax is similar to C/C++ syntax. The use of the familiar C-like syntax helped Java quickly become a widely accepted language. Experienced programmers new to Java could quickly write working code, but often this code didn't capture the spirit of Java. What was missing was the object-orientedness of Java. You'll find much of Java's OO roots in Smalltalk. Some of the current hot topics in Java aren't news at all to the Smalltalk community.
Like most of you, I'm constantly reading. To keep up with Java, I need to set aside time just to figure out what the latest APIs contain and what new tools are being developed by the open source community. Other reading is intended to "sharpen the Ginsu" so I don't keep trying to cut paper-thin tomato slices after cutting through too many shoes.
In this column, I'll recommend three books I've recently read, along with resources I've found useful along the way. Although two of the books are ostensibly about Smalltalk, reading them has improved my Java programming. As always in this column, I've got fun toys to share with you. This time, I'll point you at a Carbon Smalltalk download called Squeak that works great under Mac OS X. The Cocoa version is coming, but it's still missing some features.
Coming up in the next couple of weeks, I promise a code-packed Java-centric column. There are pending reader requests to look at the speech and spelling APIs. Other columns on the way include Java WebStart and more on XML. One of the books I'll mention in this column is Kent Beck's Guide to Better Smalltalk in the SIGS reference library from Cambridge University Press. I recommend this collection of articles about Smalltalk to Java developers. Without meaning to, Beck also included advice to column writers, advice that I have recently neglected to follow.
Last month, I promised a second installment in the XML series; I've clearly become sidetracked. I'll try to follow Beck's advice and not promise that "next time we'll look at" something unless that next article has been submitted. As always, if you have comments about this column or suggestions for future columns, feel free to email me at DSteinberg@core.com with "O'Reilly Mac Java" as the subject.
Every Java program begins its life by invoking a method with the following signature:
public static void main(String args) . Every introductory Java course has to decide how much of that signature is going to be explained to students.
Some instructors start by discussing public vs. private vs. protectected. These instructors go on to explain what a static method is. This particular method doesn't return anything and, therefore, has the return type Void. So even when you have a method with no return value, you have to explain what a return type is.
Then there is the argument that is actually an array of elements of type String. The instructor then explains arrays, primitive types, command line arguments, and possibly, how you would convert the command line argument "127" from the String whose value is 127 to the int whose value is 127. You can be well into the course before students begin to understand that Java is about objects sending messages to each other.
It's true that Java is an object-oriented language. On the other hand, quite a bit of Java programs are very procedural. Back to the first hand: The Java programming language provides the support and infrastructure for writing beautiful object-oriented programs. And yet, a friend teaching a Software Engineering course told me recently of a rather complicated application some of his students were developing that, until the seventh week of the semester, consisted of a single class. Now there are two classes, but most of the functionality remains in a multipage "main()" method in the first class.
This is not a problem that is specific to Java. Many people moved from C to C++ to take advantage of the IO streams in C++. Although they would classify themselves as C++ (and not C) programmers, many would not create or use objects. A friend at another college interviews students who have passed the advanced placement exam in C++ and want to place out of the introductory Java course. He is struck by how many of them have never heard of, or don't easily understand, polymorphism.
Despite the difficulties of the "teach all about main() first" approach, even a more object-centric approach won't mean that students grok objects the first time around. In a graduate text on algebraic topology, Walter Massey describes learning as a process of successive approximations. In OO, this means that you come to an initial understanding of how you should identify objects and let them interact. From this first approximation, you now understand enough to make a leap to a better understanding.
Some people's first approximation is better than others. I came to Java from C. I thought OO was all about inheritance and had these long, fragile chains of subclasses in my early attempts. I now judge an introductory Java text by how early (and how well) polymorphism is introduced. My second approximation to the truth came after reading Bruce Eckel's Thinking in Java and Bill Venners' fine articles on design that he still has posted on http://www.artima.com. Bruce introduced me to the power of polymorphism, and Bill's article on inheritance vs. composition was the first of many articles of his that I read and benefited from.
Daniel has touched on a number of subjects here. What do you have to add?
That brings me to my first recommendation from my current bookshelf: Joshua Bloch's Effective Java Programming Language Guide from the Java Series published by Addison Wesley. If your reading habits are like mine, it is nice to have a book split up into articles that can be read in a five- to ten-minute, ummmm, sitting. Effective Java consists of 57 guidelines split into nine categories, each providing concrete advice about programming in Java. This is a book to get you from your current approximation of how best to program in Java to your next approximation. It is written by a guy who isn't afraid to point out the mistakes he has made in learning these lessons. There are inconsistencies in Sun's APIs that drive us all nuts; this book will help you avoid making those same mistakes.
But wait a minute. What if you aren't writing APIs that you intend to publish? Bloch advises that you program as if your code will be reused. This is a concept that new programmers, particularly those learning to program in an academic setting, don't understand, and it makes learning Java a bit harder. When you design a Java class, think about how other people may use this class. "Other people" may just mean you, but think of yourself as a client for the class. What should an outsider be able to see? What services should the class present to the outside.
One of the nicest features of Effective Java is that Bloch shows the results of ignoring the rule he's discussing. In his discussion of inheritance vs. composition, he shows why inheritance makes the structure more fragile. Here he means inheritance of implementation, and not of interface.
Bloch also points out where inheritance is appropriately used. He ends the section with a wrapper class that provides inheritance of implementation through composition. The first collection of items concerns creating and destroying objects. There's standard advice such as, "avoid finalizers and avoid memory leaks by eliminating obsolete object references."
Other rules may surprise you. Two of the items include suggestions of creating classes with private constructors. The first item in the entire book suggests that a useful alternative to a constructor is a static factory method. In this item, Bloch sets the tone for the book. He provides advantages and disadvantages of using this technique and includes a code sample. The next time you're in a bookstore, pick up this book and read the first item or scan the table of contents for your favorite item. Five minutes later, you'll know if the book is right for you or not. The advice is concrete, well presented in bite size chunks, and full of examples of good and bad design.
I'm an OOPSLA newbie. I've now been to two of their annual meetings. OOPSLA is Object-Oriented Programming, Systems, Languages and Applications, and you can check out their Web site at http://oopsla.acm.org. OOPSLA is often thought of as an academic conference, but I've gotten a lot of real insight into real programming there. Next year's meeting is in Seattle in early November.
Kristen Nygaard delivered a keynote address to the educators symposium. As co-creator of Simula, he is credited with inventing object-oriented programming (although he didn't call it that at the time). Fundamental concepts such as encapsulation were included in the early Simula and inheritance was later added. Smalltalk was a child of Simula.
As an aside, think about your Mac. You have a mouse and a screen that contains windows and a dock and a menubar. You can click on these various items and they react the way they should. You expect that when you click on the apple in the menubar, the apple menu will drop down. You expect that when you click on the finder in the dock, a finder window will appear. These objects know how they respond to a mouse click and they behave appropriately. In a way, this is why kids understand object-oriented programming so much better than we do. They've spent their lives interacting with GUIs where they send messages to objects and the object handles the messages appropriately.
Many years ago, I saw Alan Kay speak at an all girls school (that's what they were called in those days) in Cleveland. He showed a video of a two year old turning on a computer, popping in a floppy, and then opening and using an application. The audience gasped. And yet, now that computers are ubiquitous, this is common place. Each of my daughters was comfortable on a computer at age two. This isn't special. Almost every kid's show has its own Web site. My five year old will ask permission to go to sites to print out character coloring pages for my two year old.
It makes total sense that the Learning Research Group at Xerox PARC, led by Kay, was developing this object-oriented language called Smalltalk at the same time they were creating a user environment that included windows, menus, icons, and a mouse. By Smalltalk-80, many Java-like features were part of the environment.
Smalltalk was a cross-platform language because Smalltalk code was compiled into bytecode that was interpreted by a virtual machine. Everything in Smalltalk is an object (no primitives) and objects are garbage collected. The goal of the core team was to create an environment that would allow children and educators to build compelling applications.
At OOPSLA, there is a core of Smalltalk folks who gather in what is called Camp Smalltalk. I thought I'd wander by and see if there was any support for Smalltalk on Mac OS X. I'd already stopped by the Visual Age for Smalltalk booth and they looked at me like I was nuts. But there at Camp Smalltalk, I saw a guy working on a Ti PowerBook. I quickly approached and asked him what he would recommend for using Smalltalk on Mac OS X. He suggested Squeak. For now, he said, use the Carbon version; soon the Cocoa version would be ready.
This brings me to my second recommendation. One of the best books I've ever read about programming in Java is a collection of articles, most of which were written before Java 1.02 was ever released. Even though the syntax of the code examples is a bit foreign, the advice in Kent Beck's Guide to Better Smalltalk is modern and immediately applicable. Of course, you'll see the roots of Extreme Programming (XP) in these articles. In "Clean Code: Pipe Dream or State of Mind," Beck takes you through a refactoring and he explains the code smells that he detects and he shows you how to fix them. Even without knowing Smalltalk, you can recognize the repeated use of a conditional being replaced by a state pattern.
Several articles concern CRC (Class Responsibilities Collaborators) cards. Invented by Ward Cunningham, these cards involve more upfront design than Cunningham and Beck probably champion today. They do provide a nice way to think about the way objects interact. A class consists of what they know, what they do, and who they know. This tool captures information about the latter two categories. Although Cunningham and Beck presented CRC cards as a technique for teaching OO to newbies, they learned quickly that experienced developers were using their tool to better understand complex systems.
Much of the book concentrates on Patterns, including an article cowritten with GoF member Ralph Johnson. The patterns here are more concisely presented than those in the GoF book, but they're no less useful. In his "Short Introduction to a Pattern Language" published in 1993, he recommends architect Christopher Alexander's books: The Timeless Way of Building and A Pattern Language. It's now almost cliche to mention Alexander's work when teaching or writing about design patterns. Alexander has probably sold more books to software designers than to architects. Beck referenced Alexander's books in a JOOP article for 1989 called "Constructing Abstractions for Object-Oriented Applications" that is reprinted in this book.
You'll recognize what later became JUnit described in the article "Simple Smalltalk Testing." It describes writing Unit Tests in the context of Smalltalk, in much the same way the article "Test Infected" (available with the JUnit download from http://www.junit.org) described the process for Java years later. Beck, together with Erich Gamma, wrote the first iterations of JUnit. At OOPSLA, Gamma demonstrated the refactoring capabilities of the open source, cross-platform IDE Eclipse, but with refactoring of some of the JUnit code. I would post the Eclipse Web site, but part of the GUI is based on platform-specific code and there are no plans to release this IDE for Mac OS X.
As a final point about this book, I almost didn't buy it. I didn't know any Smalltalk, so what would a guide to better Smalltalk teach me? As often happens, there is more to be learned by broadening experiences. Relevancies don't always reveal themselves early. As Kimmy-the-wonderwife reminds me, I learned more about collaborative learning by working in a professional kitchen than I did by attending education seminars about the topic. Again, stop in your local bookstore and read a quick article or two to decide if this book is for you.
Also in Java Programming on a Mac
The remainder of this article is brief. First, I want to urge you to download Squeak. Squeak is the current implementation of Smalltalk by Alan Kay and his team. Kay's name keeps surfacing in interesting places on interesting projects. You can read about the Vivarium project in Stewart Brand's The Media Lab and about Playground in Beck's Smalltalk book, which I recommended in the last section. There's a good amount of background in the third book I'm recommending, Mark Guzdial's Squeak: Objected-Oriented Design with Multimedia Applications from Prentice Hall. The Squeak team moved from Apple to Disney where Kay is a Disney Fellow.
Go to http://www.squeak.org and download the software. Follow the links to the download area. Under the Mac options, you'll find that you can download a Classic version, a Carbon version, or a Cocoa version. The Cocoa version isn't quite ready yet. The Carbon version is strong but you need files that don't come with that distribution. So first download the Classic version and unzip it. Then download the Carbon version and start it up. When you are directed to find an image file, browse to the .image file that was part of the Classic download. Click on the tab along the left side and choose to update your software. Once the software has properly updated, your Squeak window should look something like this.
Play with it. Open up the games and play Tetris or Solitaire. Open up the Sound and play with the music application. As you explore the different worlds, you can hear the development tool calling to you, "Hey, what cool educational application would you like to develop today?" Guzdial's book is a great introduction to developing applications with Squeak, and it includes examples that apply to object-oriented programs in general. The Squeak team, however, has been careful to add very cool features that suggest interesting possibilities to developers with imagination. Be careful; you may be sucked in.
Another great way to learn about Squeak is by checking out the Swiki.
The Swiki is a Squeak Wiki. If you don't know about Wikis, you may want to begin by wandering around the Big Wiki. Why don't you start at http://c2.com/cgi/wiki?CategoryPattern. A Wiki is a Web site where every page is editable by everybody. Please be courteous: It's an awfully cool idea that depends on somewhat well behaved participants. The Swiki allows portions of the page to be locked by the author.
The Wiki is yet another idea invented by Ward Cunningham. As a bonus book this month, you might want to check out The Wiki Way: Quick Collaboration on the Web that he cowrote with Bo Leuf. The book includes sample starter Wikis on the CD. You should go to the Web site and pick up the corrected files.
A Swiki is actually even easier to run. You can download it and have it up and running in about ten minutes. You'll find the information and links that you need at the Swiki Web site at http://pbl.cc.gatech.edu/myswiki. The spirit of a Swiki is similar to that involved in collective code ownership in XP. You'll find Cunningham's fingerprints on a lot of the XP practices.
Daniel H. Steinberg is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple's ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple's Worldwide Developer Conference, MacWorld, MacHack and other Mac developer conferences.
Read more Java Programming on the Mac columns.
Return to the Mac DevCenter.
Copyright © 2009 O'Reilly Media, Inc.