Java Reference
In-Depth Information
language, and a better understanding of why those parts of the language are useful, when to
use them, and when to avoid other solutions. Along the way, there will be some digressions
on the history of the language and environment, along with unjustified (but not, I hope, unjus-
tifiable) opinions on the art of programming, system building, and software design. There will
be times, no doubt, that the text veers from description of the language and becomes uninten-
tionally confessional, in that the viewpoints might tell the reader more about the author than
about the right way to do things in Java. When that happens, all I can say is that there is no
right way to do things in Java (or any other language), but these are ways that have worked for
me. And they may help you avoid the many wrong ways of doing things, which is no small
thing in itself.
If nothing else, I can say that what follows are some discussions of the features of Java that
I have found useful in my work over the past 15+ years. I do mostly system (more precisely,
distributed systems) programming, so there is very little about building graphical user inter-
faces in what follows. I don't do beans, or enterprise applications, so most of Java Enterprise
Edition is ignored. This is more a reflection of my experience than a reflection of those parts
of the Java environment. The fact that something isn't discussed in this topic may not mean
that it isn't a good part of Java, but rather that it is a part of Java that I haven't had to use.
This is not to say that all of Java is good. There will be times in what follows that I will talk
about things that should be avoided, or that seemed like a good idea at the time but have since
turned out to be, well…less than good ideas. Some of these are ideas that I helped bring into
the language, so I'm not going to try to assign praise or blame. But one can't talk about the
good without contrasting it with the bad. At least I can't, and I haven't tried here.
[ 2 ] There are a number of versions of this essay, but the one I usually refer to is
worse-is-better.html .
[ 3 ] See .
[ 4 ] In rereading this, I realize that the time I misspent as a youth studying philosophy is showing itself.
Please bear with me; this won't last long.
[ 5 ] Yes, this assumes that programming is a craft. I've argued this elsewhere (see
techrep/Perspectives/PS-2006-6.pdf ) and so won't rehash the argument here.
Search WWH ::

Custom Search