New to Java? We'll help you get started with our revised beginner's tutorial, or our free online textbook.

Get the latest Java books
h t t p : / /w w w . j a v a c o f f e e b r e a k . c o m /

Java Coffee Break


Learning Java

Author Profiles
Talk Java!

Using Java

Discuss Java

Looking for Java resources? Check out the Java Coffee Break directory!

Java Profiles

Michael Daconta

Michael DacontaMichael Daconta, is President of Synergy Solutions, Inc., where he conducts training seminars and develops advanced systems with Java, JavaScript and XML. He's also the author of the recently published Java Pitfalls : Time-Saving Solutions and Workarounds to Improve Programs. Whether you're new to programming, or a seasoned Java veteran, Java Pitfalls is full of useful techniques and coding solutions. In this exclusive interview, we talk with Michael about the Java language, its limitations and advantages, and "real-life" practical coding.

Arrow Read a review of his book

Q: What do you see as being the biggest change affecting the Java community in the last year?

A: Which Java community? Do you mean the Java 1.1.8 community or the Java 2 community? And there's the rub. The biggest change over the last year has been Java's slow slide from its idealistic and hallowed perch. This slide has been greased from every angle with ample skepticism. When Java began, many developers (including myself) held our breath and whispered, "Is this the ONE?" "Is this the Silver Bullet?" But now, all of our ego boundaries have snapped back into place and we are really seeing the technology for the first time - warts and all. This is where our book, Java Pitfalls, comes into play. It is a straight look at 50 programming obstacles that we guide you around. The most treacherous of those obstacles is the pitfall -- here is the definition from the book's introduction:

A pitfall is code that compiles fine but when executed produces unintended and sometimes disastrous results. Pitfalls are the bane of beginning programmers who rely so heavily on the blessing of compilation.

So, now to the good news... putting the browser and Microsoft fiasco
aside, for those developers lucky enough to be able to move on to the Java 2 platform, they have witnessed an impressive maturing of the platform. The platform has also continued its astounding growth and spread into every computing niche. The question is no longer whether you will develop in Java anymore but whether you will develop in anything else. This is especially true for the average corporate developer.

Lastly, there is another rising star that is both threatening and invigorating the Java community: XML. I see the ascendancy of XML as the greatest potential threat to Java. XML is as ambivalent to programming languages as Java is to operating systems. So, this game is really only in the second quarter.

Q: What do you see as the main advantages of Java, compared to other languages like C++?

A: A good part of my career has revolved around teaching C and C++ Pointer intricacies and pitfalls to programmers so I feel qualified to affirm that Java is a significant improvement over C++. Yet instead of going through the laundry list let's cut right to the chase: Java is a more productive language. You can produce more code, of higher quality and with less effort than if the project used C++.

Now let's move beyond C++ and discuss the key advantages of the Java platform. By far, the key advantage that provides the time-saving is the large number of continually expanding class libraries. There is over 2000 classes provided by Sun alone to provide various services to your program. That is not even mentioning open source and commercial Java Beans. So, this enormous Java support system offers a tremendous amount of leverage to the average programmer. 

Some other advantages are the well-known C syntax, the simple and
consistent heap-based storage for everything except local primitives, garbage collection, and the smart-card to mainframe scalability.

However, I cannot leave this topic without scratching off a former
oft-touted benefit: simplicity. I'm sorry but once you cross the line into phantom references, anonymous classes, deadlock scenarios and soon templates, you are hard-pressed to argue the simplicity of the language. Our book covers many of these issues, for example Item 11:
Reclaiming References using SoftReference objects.

Q: Michael, your book takes a very practical approach to Java programming. There's several other books out there on the market aimed at teaching time-saving solutions based on programming experience, but they generally focus on design patterns and aren't always Java specific. How is your book different?

A: Right from the outset, I wanted a book free from debates on design
techniques. While those books have their place, many design patterns take time (sometimes a long time) before they can be understood and
put to use. I wanted a book to help the practicing programmer right
from page one without spending hours, weeks or months attempting to map pure theory to everyday, messy reality.

As an interesting aside, the book's previous title was "Effective Java:
50 specific ways to avoid pitfalls and improve your programs." Unfortunately, at the last minute we had to change the title, due to the litigious nature of a very large publisher whose name will not be mentioned.

What does this have to do with a practical approach? All the co-authors were very sensitive to the book being compared to Scott Myer's Effective C++ so we were very careful to put out a high quality product. It is actually amusing that we had to change the title at the last minute because Java Pitfalls was the original title I proposed! So, in the end, even though we had to delay the book a few weeks, the programmers won out over the marketing suits.

The other thing that is immediately obvious about Java Pitfalls is that
all of this is coming from direct experience. We have the bruises to show for it. This material is not watered down or surmised or distilled from researching other people's work. For awhile I did a Java column called "Java from the Trenches" and that is also a good metaphor for the type of hard-won, battlefield lessons the book provides.

Q: One of the most unique sections in your book is the coverage on confusing areas of Java, and overcoming API deficiencies. How common would you say these problems are for the average programmer?

A: Having done a lot of Java training, I can tell you that the sheer size
of the Java libraries is intimidating. So, programmers are struggling
to cope with the quantity before they even consider quality issues.
Secondly, there are significant problems with the quality of the APIs
because many of them have been developed too rapidly. On one hand, Sun is pressured to move at Internet speed (some of this pressure from
internal sources); on the other hand, good APIs (like good cooking) take time. APIs must not be looked at as a land grab by software vendors. Sure, you'll occupy the territory but the structures you erect will be shantytowns.

Unfortunately, the average programmer relies very heavily on the
accuracy and intuitiveness of an API because of time pressures. The
programmer wants the straightest path to complete his current task
because he or she has a deadline to meet and does not want to be
responsible for holding up the project. So, they expect that a cursory
glance at the documentation will be enough to use the class successfully. I don't think they are wrong to assume this. Common functions in an API should be obvious to perform. Some of the existing packages and classes fail in this regard. Item 25 in the book discusses an API (part of that requires a precise ordering of the constructors under certain conditions. The documentation never explicitly states this but does state that the constructors have side effects. Under some conditions those side effects do not effect the order but for others they do. Under those conditions, if the constructors are out of order the applications lock up – so here, a deficiency in the API (constructors with side-effects) may cause severe consequences for what should be considered “intuitive-use” of the API.

Another example of a confusing API is the IO package’s loose separation between readers/writers and input/output streams. A sample of this is System.out which is a PrintStream. But wait, most people use System.out to print Strings to the console.

However, the documentation says we should use PrintWriter to print
characters for internationalization reasons. So, why is System.out not
a PrintWriter? And in JDK1.1.8 the constructor for PrintStream is
deprecated but in Java 1.2 it was un-deprecated. Un-deprecated? An API that lacks consistency also destroys the ability to use the API via
intuition. When the Java Class Libraries have grown to over 2000
classes (and rising) is it wrong to expect that the common operations of
an API be intuitive? I think not.

Many other sore spots still remain -- look at the emasculated Date
class. Every day that class remains in the java.util package is an embarrassment to the platform. It represents both poor compromise and indecision. Twenty-two methods out of thirty four have been deprecated since 1.1. This includes four out of six constructors being deprecated. Why not bite the bullet and deprecate the entire class or just fix the implementation and keep it. This wishy-washy in-between strategy is the worst of all worlds. These problems are compounded by not having a clear policy on the lifetime of a deprecated method? Is it one version, two, three? Is it 6 months, a year, two years? Just how quick do you need to rewrite those applications that have deprecated methods?

There are many other examples of poor and non-intuitive APIs that the
book uncovers: Items 19-22 cover java.util deficiencies, Items 23 - 27
cover the IO library (Item 27 on flushing Image resources especially
caused a lot of heartburn during early demos of a Java 1.0 based
telemedicine system). Of course, the GUI APIs have numerous problems and two parts of the book cover this. Especially common is the problems with GridBagLayout that Eric Monk tackles well in Item 33: How to use GridBagLayout properly.

Q: There is a section in your book on assertions, which are missing from the Java language but are likely to be introduced in future versions. Many programmers are looking forward to support for pre-conditions and post-conditions in Java, and I'd be interested to know if you feel there are any other areas where the Java language itself could be improved.

A: To examine what is planned for assertions check out JSR-14, A simple Assertion Facility, at

As for new features, I am a minimalist -- I would first like to see the
language protected more vigorously from the "good idea fairies". I have always liked James Gosling's take on this -- if you are not sure of the correct answer, don't put it in there. Hopefully, JCP 2.0 will accomplish this.

There are a few areas of improvement I would like to see research on:
Chief among them is better support for reliability guarantees. This can
take several forms. At the language level it may call for formalisms to
express requirements to allow better compile-time validation of a
program's correctness. At the VM level, we should have a "safe-mode" of VM operation that provides runtime null pointer checks, guaranteed safe threading, heap scans, etc. Another neat feature I would like to see work on is the ability to return to the statement of an exception origin. That way you catch the exception, and if you are able to fix the condition (like free up memory or disk space) you then start back from where you left off. In general, good exception handling is hard to find and I see this as an area that needs a lot more work and experimentation. In Java Pitfalls, Item 17 (Handling Exceptions and OutOfMemoryError) covers some of the exception handling issues.

Q: In Java Pitfalls, you and your co-authors do a very thorough job of covering common difficulties programmers are likely to experience in their projects, ranging from language specific issues, to the utilities and graphics libraries. It struck me odd, however, that no networking pitfalls were mentioned. Is this because you feel that the networking API is particularly simple to use, or that it might not be part of the average programmers' work?

A: There is one item that uses the package: Item 25 Sending
Serialized Objects over Sockets. Barring this exception, you are
correct in that our coverage of the network package is nonexistent. The archive of the RMI-Users mailing list at provides ample
evidence that there are many pitfalls there. The reason for this omission was that we kept the book to 50 items and that package did not make the cut. If this book is well received, there will be a book called either More Java pitfalls or Java Pitfalls Volume II.

Q: A second edition is something that many readers will look forward to. While we're looking to the future, where do you see Java heading? Is there a particularly dominant technology (e.g. J2EE, CORBA, Jini) that you feel will change the direction of Java?

A: I'd like to answer this question in two ways -- generically and

In general, all other technologies (operating systems, middleware,
component architectures) are being affected and adapting to the lessons learned from the Java phenomena. In fact, the reasons that Java has succeeded are more important than Java itself. One reason Java succeeded is because computers have become fast enough to make interpreted languages ok. This is also why XML will succeed because computers have become fast enough to make “data as text” ok. The exciting part of this is that computers are now fast enough to allow us to create this new software service layer above the operating system. To do this we are categorizing and formalizing the necessary services and transactions to propel our applications to new levels of complexity, reliability and sophistication. This is part of an overall maturation of the software development industry. It is an exciting time to be a software developer.

Specifically, the future of Java will be dominated by extending the
container-run software concept just begun with Java Beans and EJB.
Those two technologies are the tip of a large iceberg that will lead us
to more reliable and more ambitious software. It is the start of the
specialization of the software industry. I expect to see new
container/environment based paradigms with more component support, more component layers, more component interaction paradigms, more standard component categories, and many more standard components. Components should not be seen as a threat to the average software developer.

Programmers will not be replaced by assemblers, instead components will merely increase the size of our building blocks and with it the size and grandeur of the software structures we can build.

Q: Thanks for your perspective on practical Java programming, and the language's future. Michael's book, Java Pitfalls, is published by John Wiley & Sons, and can also be purchased online through

Back to main

Copyright 1998, 1999, 2000 David Reilly

Privacy | Legal | Linking | Advertise!

Last updated: Monday, June 05, 2006