This page contains some notes about the development process and what
I like and don't like about Java. Most of it is pointless rantings.
Feel free to skip it...
Taprats got really big really fast! I was aiming for about 5000 lines of
code. The whole system weighs in at 12540. Mind you, that includes
Anyway, It's a testament to Java that I was able to construct such a
large system in so little time. Here are some things that help:
- The package system
- Java does modularity really well. Having the package system
around greatly simplifies the organization of a project's sublibraries.
Also, knowing it's there is a big incentive for thinking about
how to best factor your code into packages. Associated with this
is the broad range of access specifiers, including package-level
access. I think there are probably too many of them, but having
learned how to use them, they're very powerful.
I've tried organizing my C++ projects in a Java-like package structure,
but the overhead is just too high.
- Multiple entry points
- I love the fact that I can throw a main() into every single class
I write and test that class as a unit without building a make
file, linking and maintaining a whole big separate dang program.
It's a lightweight way to get the benefit of unit testing.
A quick check reveals that in the Taprats source code, there
are 37 mains defined in 66 files. And Taprats isn't even an
application! I challenge you to do that in C++!
- Inner classes
- I'm sure we can all agree on the benefits of inner classes, both
anonymous and not. I find they're tremendously useful during development.
They allow you to insert the code you're thinking about
while you're thinking about it. You don't have to go to a
distant place in the file to write a helper class. You can
insert it inline as you're writing the surrounding code. It's
one of the best ergonomic benefits of functional programming,
here in the OO world.
I have only one request, Java people: have a way to specify a
constructor in an anonymous inner class. That would be the last
barrier towards total utter coolness. It demands some sort of
new syntax (perhaps Python's
__init__?) but it's
- Exceptions with stack traces
- I love these! Often, a stack trace is all I need to find a
bug in my code. And I don't even need to think about it. If there's a
bug, out comes a stack trace. This makes a huge difference in productivity,
and after returning to Java after a long C++ project, I feel like I'm
making fewer serious errors and the ones I make go away faster.
To balance out all those good things, here are some things I don't like
in Java, or at any rate didn't use:
- Java 2
- You'll notice the conspicuous absence of anything from Java 2 in Taprats.
Most notably, I don't use the Swing components and I don't use Java2D,
which seems like a crime given the graphics Taprats does.
Look, the Java people have done tremendously good work in advancing
the Java state of the art. They haven't let the project get away
from them. But I don't think the new stuff is ripe yet. My officemate
is using Swing for a very large project and it still seems a bit
clunky without offering that much over plain AWT. I'm all for the
philosophy and design, but Java implementations and the library itself
need to mature a bit.
As for Java2D, I was very excited when I first heard about this project
a few years ago and I did everything I could to wait until it was
ready so I could pounce on it. In the meantime I needed something to let
me do my research in geometric art, so I wrote the code that eventually
became GeoView. Given the limited kinds of 2D graphics I'm doing,
I don't have a compelling reason to switch over to the heavyweight
Java2D yet. But I'm looking forward to using it for some future
Finally, let's not overlook the pragmatics of the situation, summed
up in the three Ls: Learning curve, Legacy and Linux. I am familiar
and comfortable with the 1.1 AWT and don't want to jeopardize a
project like this with a failed attempt to transition to Swing.
I can adapt some classes I've already written from other projects
to do what I need to do. And I do it all on Linux, where (at least
up until recently) the state of the art was lagging so far behind
that I had no recourse for learning the new libraries.
- Java IDEs
- This project was developed using the command-line 1.1.7v3 JDK from
blackdown. And yes, every single file in this project was edited
with vi. I'm not a die-hard vi fan (even Bill Joy said recently that
he marvels that anyone still uses his editor) -- it's a simple learning
curve issue again. I'm very efficient with vi -- it's built into
my fingers. I believe in emacs, it's just hard to move to it
when it slows me down so much.
As for IDEs, I have yet to try a single IDE that even makes me come
close to leaving a simple text editor. They have awful user interfaces
and mouse-centric editors. The useless features consume real estate
and the good features hide in some dark corner. Really the only thing
the IDEs have that I want is a debugger. I've never been able to
get Sun's JDB to work. I eagerly await the completion of the Java
front end for gcc. Still, debugging print statements work very well
in Java given the combination of stack-traces-on-the-fly, and rapid
compilation times with no linking.