Skip to main content

Writing Good Code: the Present, Future, and Past

Posted by editor on April 27, 2009 at 8:30 AM PDT

In The Developer Insight Series, Part 2: Code Talk, Janice J. Heiss interviews five distinguished developers on the topic of developing good code. Last week I reviewed the first installment in the series, where developers are advised to "write dumb code"--that is, code that is sufficiently straightforward so that the compiler can "understand" the code sufficiently to do a good job in optimizing it.

In Part 2 of the series, Google chief Java architect Joshua Bloch and Sun software engineering manager Masood Mortazavi elaborate on this theme. Meanwhile, virtual reality pioneer Jaron Lanier and Grid Dynamics CEO Victoria Livshitz believe there are better ways to create code than how we do it today. And debugging ace Brian Harry talks about the benefits of an historical perspective in fixing bugs.

Joshua Bloch warns developers to beware of unwarranted optimism:

To be a software developer, you have to be an optimist -- otherwise, it would feel like a losing battle. Generally, this is a good thing, but it has a downside: Optimism can lead to overconfidence. It's easy to feel like the general warnings about premature optimization don't apply to you, because you just know which code is time-critical and how to make it fast. But no one can determine this without measuring before and after each attempted optimization.

Masood Mortazavi talks about how the best code makes the least assumptions:

For the logician, thinking of programs as a structure of predicates with bound and free variables can be very helpful. What's called a good "method" in Java, or "function" in other, traditional programming languages, is one that avoids local variables, which only serve for internal bookkeeping. The more internal bookkeeping we do, the more verbose our program becomes, which means the code will begin demanding that we break it up into more classes and methods.

For Jaron Lanier, the way we think about software is wrong:

The problem with software is that we've never learned how to control the side effects of choices, which we call bugs. We shouldn't be complacent about that. I still believe that there are ideas waiting to be created and that someday we will have new ways of writing software that will overcome these problems. And that's my principal professional interest. I want to make a contribution to making bugs go away.

Victoria Livschitz believes the solution may lie in a programming language that is a notch richer than OO:

I don't believe that future advances in software engineering will prevent developers from making mistakes that lead to design bugs. Over time, any successful software evolves to address new requirements. A piece of code that behaved appropriately in previous versions suddenly turns out to have deficiencies -- or bugs. That's OK! The reality of the program domain has changed, so the program must change too. A bug is simply a manifestation of the newly discovered misalignment. It must be expected to happen, really! From that vantage point, it's not the prevention of bugs but the recovery -- the ability to gracefully exterminate them -- that counts.

Brian Harry advises in fixing bugs, look at earlier versions of the plaform:

if you're doing a Java code fix, don't just look at the current version of the platform. I've routinely tested out bug tests on 4.0, 5.0, and 6 to investigate when a problem started and stopped. See if you can find why something started. My "uninitialized" problem has roots in the verifier spec. JDK bugs will have roots in some historical moment. Getting a bigger picture may provide clues about the design factors that led to the bug.

Once again, Janice Heiss has put together an interesting and thought-provoking set of interviews with developers who have been around long enough to really know what they're talking about. It's probably no surprise, though, that even among these much experienced and highly successful software development professionals, there is a variety of opinions on the past, present, and future of software engineering.

The latest Java Mobility Podcast is
Java Mobility Podcast 77: Java and Symbian OS, in which Roy Ben Hayun talks about applying Java ME on the Symbian OS.

In Java Today, JavaTools Community Newsletter - Issue 195 has been published: "A new edition of the newsletter is available, with news, new projects and tips! If you want to receive the newsletter by email, please subscribe the announcements mailing list - or read the current issue here."

Vikram Goyal published a new Mobility Tech Tip related to JSR 179, titled Using the Location API for Favorite Spots: "Developing location-aware applications seems like a lot of work, especially since getting started seems to be the hardest part. In this tech tip, I will show you how to get started using the Location API (JSR 179) to get over the initial hurdle, and build a small location-aware application that you can use to tag your favorite spots. I have tested and verified that the MIDlet works on a Nokia N95 device. When testing this on your device, make sure that it supports the Location API (JSR 179)."

And Josh Marinacci has come up with a JavaFX overlay that lets you Right Click to View Source: "One of the criticisms of many RIA technologies is the lack of a right click menu which lets you view the source of the app. But it doesn't have to be that way. It's a tad bit more work than regular webpages, but you can add a view source menu to your own application very easily with just a single class and an ant task."

In today's Weblogs, Lance Andersen published Getting started with Mercurial and OpenJDK on Solaris: "A gentle guide to getting started with OpenJDK and Mercurial on Solaris. As I am about ready to start checking in some bug fixes and enhancements to the JDBC and RowSet code in Java SE, i figured i should finally spend some time configuring my Solaris 10 box for Mercurial..."

Osvaldo Pinali Doederlein reports JDK 6u14 almost ready at b05; Making Java load faster and lighter: "A new build (possibly RC? FCS is scheduled for May) of the next JDK is available. A relatively small number of fixes this time, nothing major. But I reviewed the last builds and tested the improvements for loading time. As a bonus, some musings about Java's loading time and resource usage..."

And in JavaFX finally peaks my interest Dominic Da Silva writes about his new understanding of JavaFX: "So I headed to the Orlando JUG meeting tonight for a talk by Jim Clarke on JavaFX. Needless to say I was impressed with not only the JavaFX language and what Jim was able to do in the short space of time of 2 hours. The kicker for me was being able to drag an in-browser JavaFX applet out of the browser and have it run standalone on the desktop, in its on JVM sandbox, even after the browser is closed..."

This week's Poll asks "Which aspect of Java technology is the primary focus your current work efforts?" Voting is open through Thursday, April 30.

This week's Spotlight is The Developer Insight Series, Part 2: Code Talk, in which Janice J. Heiss asks renowned developers about the keys to writing good code: "In Part Two, we hear code advice from five distinguished developers: Joshua Bloch and Masood Mortazavi echo Goetz's advice to keep code simple. Jaron Lanier and Victoria Livschitz want to radically change the way code is created. And renowned bug fixer Brian Harry provides tips on bug fixing while emphasizing what the process can teach us."

In the Forums, Mark Mielke poses the question Dependency injection - when to clean up injected resources?: "This feels like a newbie question - but it seems like this is a friendly group, and I've read through all of the specs and faqs and plenty of examples and I have been unable to find a solid answer here. Most examples of dependency injection do not clean up the injected resources. Whether DataSource, EntityManager, or EJB. The resource is injected, it is used, and resources allocated from it (like a Connection from a DataSource) are cleaned up, but the injected resource itself is not cleaned up. My assumption has been that these resources are safe to leave around. That is, they're only taking up memory which is the job of the garbage collector to deal with. They're not tying up any resources. In some cases like EntityManager or a UserTransaction, the container will always clean up any non-memory references held after the business method returns when the transaction is committed or rolled back..."

ido_ran asks the community about Transaction Scope - Web Application with EJB Project: "Hello, I'm new to GlassFish and J2EE so I hope I'm asking it right. I have an enterprise application which contain Web module and EJB Module. The EJB is the business logic which contain entity classes as well as session (currently only stateless) bean which manage them. There is nothing to fancy here, mostly boilerplate code for creating, updating, getting and deleting the entities. The Web module is a RESTful interface to the EJB module. I have resource and converter (item-container pattern) which expose the entities. Everything is working good except of the transaction management (I think) and I'll explain. I'm experiencing two issues: one is I get an LazyInitializationException when accessing a collection of a loaded entity in the web module. For example, I'm loading Process entity which has collection (OneToMany relation) of Activity entity. When I call getActivities on the Process I get the exception. As I understand it means that the entity manager which was used to load the Process entity is close by now..."

And tmilard is having problems with Re: 1.6.0_14-ea regression issue on Double JVM launch: "Well I could see it because simply ... I have a console opening each time a JVM lauches. So when I had Update 14 installed I could see : - after a few seconds a JVM console opens up. - First line written was something likle "Java Plug-in 1.6.0_14" so I am quite sure it was an issue of update 14. - Then I drag the console a bit on the right of the screen ... just to be able to see if some other console shows up. - After the tests (too long by the way) of the difffferents jar server-client ..... tatam : A new console opens up then rus my program ... while the first one (on the right of the screen) slowly vanishes and closes. So voila, 2 VM it seems : One to check the jar, do the technicall things, read JNLP file and the second to (really) run my program..."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

In "The Developer Insight Series, Part 2: Code Talk", Janice J. Heiss interviews five distinguished developers on the topic of developing good code...