Re: AspectJ: solution to Java's repetitiveness?
jhc0033@gmail.com wrote:
I'm an experienced and multilingual programmer who, until now, avoided
becoming too familiar with Java.
While I'm very impressed with the Eclipse IDE for Java and the
performance improvements JVM has apparently made, I'm unimpressed by
the amount of error-prone boilerplate code that programming in Java
still requires.
Firstly, there is the pervasive repetitiveness of Java code. For
example, for most classes, it makes sense to define, say, clone(),
equal(), toString(), toXML(), fromString, fromXML() for all of them.
All of these operations follow a very simple pattern that can be
easily formalized. However, Java programmers have to implement each of
these methods by hand for every class. Another common example is the
trivial getters and setters.
I'd agree on toString() but on none of the others. (Unless
by equal() you actually meant equals(), in which case I'd say
it makes sense for many classes but not "most," and you should
implement hashCode() at the same time.)
Secondly, there is the relatively minor issue of verbosity. Consider
this fragment:
Bar b = new Bar(x, y);
Why not
b = new Bar(x, y);
Calendar cal = new GregorianCalendar();
Number num = new Double(42.0);
JComponent container = new JPanel();
List<? extends Number> list = new LinkedList<BigInteger>();
...
If b is a member or a local variable - assign to it. If it isn't,
declare it
Ugh. Myself, I'd prefer that the compiler complain when
I misspell something, rather than trudge silently and obediently
onward in an unintended direction. If you want FORTRAN, you know
where to find it.
Thirdly, there is the general issue of language extension. If the
creators of the language did not implement a certain policy, such as
the automatic generation of clone(), equal(), toString(), toXML(),
fromString, fromXML(), and I would find it very useful in my project,
how could I extend the language to do these and other things for me?
(For Lisp programmers reading this, I'm basically thinking of
defmacro)
Can AspectJ address these issues?
I don't know, but I find it hard to imagine a code
generator that would do a good job of toString() and equals().
Perhaps for very simple classes whose instance variables are
few, final, and "fundamental" something could be done, but
for anything of even moderately higher level I think the
generator would have a hard time figuring out which instance
variables should and should not show up in toString()'s result
or contribute to equals()' determination. For example, a
class that fires ChangeEvents to ChangeEventListeners most
likely has an instance variable that's an EventListenerList
or something similar, but you almost certainly would not want
that instance variable to contribute to toString(), nor to
equals() and hashCode() ...
If you'd prefer a more "declarative" style for your coding,
you might want to look into using annotations. I haven't used
them extensively myself, but the framework looks rich enough to
support "This instance variable does/doesn't influence the
toString()/equals()/hashCode()/compareTo()/... methods."
--
Eric Sosman
esosman@ieee-dot-org.invalid