Re: AspectJ: solution to Java's repetitiveness?
jhc0033@gmail.com wrote:
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.
Those methods are not implemented for most Java classes.
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.
Getter and setter code can be generated by your IDE (if not then
switch to another IDE).
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);
If b is a member or a local variable - assign to it. If it isn't,
declare it (Note: I'm not proposing automatic member declaration, like
in Python) Following the capitalization of classes convention, one
might even trim this down to
b = Bar(x, y);
That would not be Java.
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?
AspectJ can extend a group of classes with certain functionality.
I don't think you will want to do what you are describing.
And I doubt that AspectJ can do the specific extensions
you want.
If it can, can it do so without compromising the runtime performance
compared to writing the equivalent code by hand?
AspectJ weaved in aspects add some overhead, but are still reasonable
fast.
Also (and this is unrelated to the performance question), can AspectJ,
or at least its compile-time functionality be used with GWT (a Java
source to JavaScript compiler), which is my main motivation for
looking at Java?
I don't think so. AspectJ is for Java byte code. GWT generates
JavaScript.
Arne