News

Build Web Apps With Java

• By Lee Thé
• 12/21/2007

The hall was packed, despite the fact that Bloch hadn't been on the team that created GWT. He is a Java maven, however, who among other accomplishments led the Sun design team that built many Java platform features, including the JDK 5.0 language enhancements and the Java Collections Framework.

Doench asked how many people in the audience were Java developers, and nearly everyone raised their hands. So this conference was a good fit -- especially since GWT was designed for people who want to build Web applications in Java and then compile the apps to JavaScript/HTML. It allows developers to use frameworks such as Eclipse, debug more efficiently at compile time and use familiar tools. It probably says something about GWT that when Doench asked the audience how many were JavaScript developers, only a handful raised their hands (JavaScript is unrelated to Java, despite the name).

Speed Counts If Your Aim Is True

Doench led off the discussion by asking Bloch about speed. You'd think it's a no brainer to design Web applications for speed, but Bloch was having none of it.

"Speed is good," he said, "but first you have to build the tool to solve the problem. It doesn't matter how fast it is if the user experience is painful."

However, Bloch did add that in your API design, you cannot commit to anything that prevents speed optimization later.

C++: Yesterday's News

Doench then asked Bloch about C++. He got the kind of answer you'd expect from a Java architect speaking to a Java developer audience. Bloch said C++ isn't as robust as Java -- in particular, that C++ lacks a safe type system. Typing is a form of foolproofing in which a language doesn't let you perform operations not allowed by a value's data type.

Actually, C++ is considered a strongly typed language. But Bloch probably meant that Java is even more strongly typed than C++ (JavaScript is considered "weakly typed," but it could also be described as "auto-typed" since it automatically assigns type from the context you give data, such as a dollar sign).

Bloch took a few more shots at C++, pointing out that as it gets older it gets bigger, "and the more stuff you have to support, the nastier compilation gets." He added that this is one reason why integrated development environments (IDEs) for C++ tend not to be "as spiffy" as IDEs for Java.

Moreover, C++ has a macro processor for doing certain operations just prior to compilation (Java neither uses nor needs this), and that doesn't help with IDE spiffiness either, he said. To be fair, there are C++ experts who love its macro processing support and just think it has been misunderstood. Many others agree with Bloch, to be even more fair.

Java's Success

Bloch listed the Java platform's best features:

1. Knowledge base. "It has become the de facto standard teaching language in high school and college programming classes for the past 10 years, so you leverage off everyone's knowledge."
2. Tools. "Java has a rich ecosystem of tools around it." Bloch asked how many in the audience use Eclipse, and half raised their hands. He went on to praise Eclipse: "The IDE is great and it's free to boot." And he said that there are all sorts of great tools that work with Java, along with some great libraries. "You know the collections framework," he said. "All that stuff just works in Java." A collections framework provides a unified architecture for representing and manipulating collections independently of their representation.
3. Safe Language. Java is a safe language. Among other things, here Bloch was alluding to the fact that Java catches errors at compile time instead of at run time (as JavaScript does). That way you find the mistakes before your users do.
4. Books. "All these great books about Java are available." This point led Doench to ask Bloch about when folks could expect a new edition of his book "Effective Java." (The new edition should ship on May 28, 2008, according to Amazon.com.)

"Effective Java" includes an essay on aesthetic factors, with a "great pattern called the builder pattern," Bloch said. He promised an essay on it and how to use it to combat the problem of large numbers of threads, adding that the platform has to evolve beyond the threading solutions in the original version of Java, which were great ... 10 years ago. He also promised an update of the concurrency chapter. Bloch has produced a slide show on some of the content that's going into the revision.

There was a short discussion of the fact that no one planned on GWT being pronounced "GwiT." It just happened.

Java Improvements

Doench observed that each new release of the GWT framework delivers "huge improvements in performance." So "how is Google making that happen?"

Bloch's answer was "good software engineering," and explained further.

"If you design a nice system, people code to it," he said. "Then, if we improve strategies for caching, comm protocols and the like, everyone will realize gains without changing their code."

He pointed out that programs written in Java 1.0 run 20 times faster today due to better compiling, improvement of hot spots, "all manner of tricks" and the libraries themselves. According to Bloch, the API was good but had a "crappy slow implementation of thread locals." (These use static or global memory local to a thread.)

However, people started using a lot of thread locals. So Bloch and his peers had to make thread locals faster and faster through several complete rewrites. Something similar has happened with array sorting, Bloch added.

"It's nice because it's a stable sort," he said, "but it's not a terribly fast merge sort" (a comparison-based sorting algorithm). "Meanwhile Python [an open source programming language] came along."

Bloch liked Python's sorting functionality, so his team adapted it to Java as a drop-in replacement that's up to 10 times faster.

"It takes advantage of existing order in an array," Bloch said. His bottom line was that "if you design a platform with nice APIs, people's code just gets faster."

Getting back to the topic of the conference, Doench asked Bloch if you should use GWT for everything. Bloch replied that you have to use the right tool for the job, but that GWT is right for many. Doench then asked about Ruby on Rails, another Web development framework with more of a server-side orientation compared with GWT's client focus.

Bloch said he's not a Web programmer. He's a Java guy. He has heard that Ruby on Rails is a nice system for getting database middle tier stuff up and running very quickly if it's simple -- like writing an application in JavaScript.

Build Huts With JS, Skyscrapers With Java

There's a fundamental conflict between people who have to do things with a static language (such as Java) versus people who are diehard zealots for dynamic languages (like JavaScript), according to Bloch.

"If you're using a language with a strong static system," Bloch said, "you'll spend more time programming it and find more errors at compile time." For example, you won't end up sending a message to an object that won't know what to do with the message.

"So it takes longer but the code is more robust," he explained. "The set of states that a program can be in -- especially with concurrent programming -- is exponentially huge. Tests can never show that a program is correct; they can only show if it's incorrect. You can't test for all cases that are possible. So ... given that you can't test exhaustively, it's better to catch bugs earlier. Changes may have repercussions later on."

Doench wanted to know what benefits Java brought GWT at the fundamental semantic level. According to Bloch, scripting languages are great for bashing things out in a hurry. He compared scripting languages to tools you need to build a hut versus what's needed to build a skyscraper.

Find Bugs With FindBugs

One tool Bloch singled as a great example of skyscraper-class tools was FindBugs, a free program that uses static analysis to look for bugs in Java code. He asked how many in the audience were using it. Only a few raised their hands. Bloch urged them to try it.

"It's magic. You can pull a class file off the Web and FindBugs will tell you the bugs you're likely to find. They have bug patterns. The book Java Puzzlers [which Bloch coauthored] has programs that look reasonable but have bugs. Bill Pugh [creator of FindBugs] went through this book, found patterns of bad behavior and then coded the patterns into FindBugs. You can go to a commercial software vendor, download its class files and get precise bug reports."

Testing 1-2-3

The discussion turned to best practices in testing. According to Bloch, testing is necessary -- critically necessary -- but not sufficient.

"I have some misgivings about agile [highly iterative] practices," he said, but he loved "making unit testing sexy." This involves testing every unit of source code that can be tested separately.

"Run them any time you touch a line of code. Make a small change, run the test, fix the bug."

However, Bloch cautioned that JT harness, Sun's general purpose Java unit test platform, doesn't work well for concurrent programs. "If an error occurs in a background thread it won't catch that."

Get the Requirements

Bloch's bottom line about Java programming is that you have to understand the requirements before you start coding.

The biggest failure in programming is that "people don't know what problem they're trying to solve," he said. "And just going to customers isn't enough." Customers usually have an important perspective but it's usually limited. So it's up to you to really understand the requirements.