Java Profiles
Michael
Daconta
 Michael
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.
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 java.io) 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 http://java.sun.com/aboutJava/communityprocess/jsr/jsr_041_asrt.html.
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 java.net 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 http://archives.java.sun.com/archives/rmi-users.html
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
specifically.
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 Amazon.com
|
