Eiffel inventor, Bertrand Meyer, gave an interview on artima recently. He makes reasonable points in the first two parts.
And then he mentions Eiffel (which he never fails to do).

I learned Eiffel in college a long time ago and it was quite an ordeal.  I
suspect the tools have improved quite a bit since then but the
language itself remains a puzzling mix of very questionable design choices for
an object-oriented languages, such as renaming imports a syntax that will
make you miss C++.  A lot of these features made sense back then when we
didn’t know better and Java didn’t exist, but I would argue that by now, we have
a pretty good idea of which object-oriented concepts are sound and which ones
should stay in the realm of academia.  As far as I
can tell, Eiffel hasn’t really learned these lessons as of today, but that’s not
the point of this posting.

Eiffel is vastly different from the C++/Java family
of languages, and there are undoubtedly dozens of different things you could
discuss in such an interview, but instead, Bertrand tries to make the point that
assigning fields is evil:

For example, in just about every recent object-oriented language, you have
the ability, with some restriction, of directly assigning to a field of an
object: x.a = 1, where x is an object, a
is a field. Everyone who has been exposed to the basics of modern methodology
and object technology understands why this is wrong.

Well, no.  Just saying "everyone understands it’s wrong" is not going to
make it suddenly a reality.

Without even discussing whether this is a good point or not, reducing 
most of the complexity of today’s software base to this simple concept is
laughable. And the quasi non-existence of Eiffel in the industrial world since
its inception (almost twenty years now) doesn’t seem to bother Bertrand Meyer at
all about the validity of the choices he made when he designed Eiffel.

Eiffel sports some very amusing archaisms, such as the absence of
overloading.  The
justification is worth a read (from the
FAQ):

Readability is also enhanced when overloading is not possible. With
overloading you would need to consider the type of the arguments as
well as the type of the target before you can work out which feature
is called. With multiple inheritance and dynamic binding this is
awkward for a compiler and error-prone for a human.

"awkward for a compiler"?  Now that’s a good one.  Code is code. 
It might be a difficult problem to tackle, but refusing to implement overloading
and choosing instead to support multiple inheritance of implementations makes me
wonder about the sanity of the ISE engineers.

Even now,
Bertrand Meyer is certainly still convinced that overloading is evil:

This kind of apparent short-term convenience buys a lot of long-term complexity,
because you have to find out in each particular case what exactly is the
signature of every variant of an operation.

Well, this is called a "paradigm shift".  And by the way, the
paradigm shifted at least ten years ago, and I can guarantee that by now, programmers are pretty much used
to read polymorphic overloaded methods.  Especially with modern IDE’s.

Besides, I happen to know for a fact the original motivation for leaving overloading out
of Eiffel (my teacher was a close friend of Bertrand Meyer).  Back then,
Eiffel was generating C, and overloading is not supported in C.  Of course,
it never stopped the original C++ compilers (cfront) from solving this problem,
but it looks like the ISE engineers have decided that this problem was too hard
for them.  And they haven’t revisited their choice since 1985.

Finally, one last gem:

“if it looks too good to be true, then it must not be true,” which is certainly the stupidest utterance ever proffered by humankind. This is the kind of cliche
we hear from many people, and it’s just wrong in the case of Eiffel.

Bertrand can rest assured: anyone who sees an Eiffel program for the first time will definitely not think “it’s too good to be true”.

Read the rest of this entry »

Rickard is making a few changes in his views on AOP, more specifically on dynamicity:

Basically, each class (be it a normal class or aspect implementation) simply declares what it it needs in terms of other interfaces in the “implements” clause, but does not actually implement them.

I find this idea puzzling. While it does indeed help solve the static typing problems, since your classes and advice now really implement the interfaces that the AOP framework might have introduced on them, you are still left with the problem of object identity.

For example, in his example, the class PersonMixin declares that it implements Person and Author, but the class is declared abstract and the Java code only implements Person. The implementation of Author will be supplied by the AOP framework in a mix-in.

I don’t know about you, but my first reaction is that this reminds me a lot of how CMP 2.0 works. You work on an abstract class that only contains your business logic and all the abstract methods are generated by the container in a subclass. The difference with Rickard’s AOP approach is that he uses CGLIB to implement the concrete class and, more importantly, that the generated subclass can be controlled by a pointcut model. So far, so good.

However, unless I am missing something important, I just don’t see how this could work beyond a toy application where objects can be populated statically. The problem is that at runtime, you just don’t know what instance of Author you will be talking to. How do you make sure it’s the right one?

In the case where this class can be populated statically, you can use something like Spring’s BeanFactory to get you started. However, I suspect that in the real world, the Author object is populated at runtime. Its value is part of your business logic, and I don’t see how you can guarantee this in an AOP framework, unless you start putting the said business logic in your pointcut definition. An idea which, frankly, scares me.

Maybe you could envision having an advanced version of PicoContainer that knows about identities of objects and allows you to look them up, but do we really want to go down the path of defining primary keys in Java objects just so that we can use them in-process?

I wonder if this idea is simply not going too far. AOP makes us think about proper divisions or responsibilities and concerns, but this idiom is a step toward splitting your business logic between Java code and… some other undefined place which depends on your AOP framework.

Rickard, if I missed something, please let me know.

By the way, all these problems magically go away with AspectJ, which combines:

• Static typing.
• A powerful pointcut model.
• Familiar OO concepts such as inheritance and polymorphism.

If you are curious to see how Workshop supports EJBGen, take a look at
this article on dev2dev.

Also, I just noticed that the EJBGen mailing-list has passed the 600 subscribers. It looks like there are still a few people using EJB’s after all…

Reminder:  I will be making a presentation on Aspect-Oriented
Programming tonight at the
Java by the Bay, downtown San Francisco.  Stop by and say hi.

As you probably all know, JSR 175 will enable annotations for Java programs as
part of the JDK.  The current method, using Javadoc, will slowly be phased
out and replaced by this JSR which defines models for

• The annotations.
• The class file format.
• An API to access the annotations.

The current Javadoc approach is very fragile and non-standard, but it does
have a fairly strong point in its favor:  it is totally non-intrusive.

Consider the following Stateless Session Bean defined with EJBGen
annotations:

/**
 * @ejbgen:session
 *    ejb-name = statelessSession
 */
public class TraderEJB implements SessionBean {

 
/**
  
* @ejbgen:remote-method
  
*     transaction = Required
  
*/
 
public void buy(String stockSymbol, int shares) {
   
// buy shares
 
}
}

This Java source file doesn’t have any dependency on EJBGen.  You can
compile it with any Java compiler as long as you have the J2EE libraries in your
classpath.  No need for ejbgen.jar.

Now consider the JSR 175 equivalent:

import com.bea.wls.ejbgen.annotations.*;

@Session(
 
ejb-name = "statelessSession"
)
public class TraderEJB implements SessionBean {

 
@Remote (
     
transaction = Required
 
)
 
public void buy(String stockSymbol, int shares) {
   
// buy shares
 
}
}

This file will not compile unless you have the EJBGen annotations (com.bea.wls.ejbgen.annotations.*)
in your classpath.  You have just tied yourself to a tool.

Now imagine that this source file uses other tools as well, mixing several
kinds of annotations such as Struts, AOP, etc…  Suddenly, your
dependencies shoot up the roof and a simple source file like the one above ends
up pulling a big set of JAR files before you can even run javac on it.

Here is another example:  you send me an MBean source with annotations
from a tool that helps you create MBeans.  I want to be able to build that
MBean even if I’m not using your tool.

How about IDE’s such as Rational that save information as annotations in
their Java files.  With JSR 175, you will no longer be able to compile
these files unless you have the Rational classes in your classpath.

The common point in these examples is that the class can be useful
without the annotations, which are merely hints used by third-party tools to get
a certain job done faster.

What can we do about this?

The first idea that came to my mind was to make annotations optional to javac. 
If the compiler cannot locate an annotation type, it will emit a warning but
keep compiling.  This is similar to the Javadoc behavior, which tries to
make a full transitive closure of all the types in your source files, attempts
to locate the dependent source files but simply issues a warning if it can’t
find them and keeps going.

After all, all this means is that no documentation will be available for these
dependent classes, but it shouldn’t stop the tool from producing documentation for the
supplied classes.

Another way to mitigate the problem would be for tools to be distributed in
two parts:  the annotation jar file (or even better:  the annotation
source files) and
the "real" (runtime) jar file.  Compiling the above source file would still make you
depend on EJBGen, but only the annotation part, not the whole runtime.

What do you think?

• Should javac have an option -ignoreAnnotations?
   
• Should this flag be turned on by default?

A few additional thoughts on the

"Half-Bean" technique.  Brian says:

If I add a final instance variable to Album and forget to set it in the
constructor, the code won’t compile.

Mmmh, yes, but you need to remember to use "final".  And also not to
assign it directly in the declaration.  If you don’t religiously do these
two things (I don’t know about you, but I pretty much only use "final" on
constants), my original complaint applies:  you have no way to remember you
need to update the Builder class every time the main class changes.

On a slightly different topic:

Making Strings immutable was a wonderful choice

I wonder about that.

One of the main reasons why String is immutable is performance.  While trying to make Java
faster, the designers pushed an optimization decision on us, poor programmers,
who are now paying a dear price.  String is immutable, but the fact is that
we need mutable strings on a daily basis.  How did the Java designers solve
this problem?  By silently introducing StringBuffer objects whenever the
operator "+" is applied
to a String.

The consequence of this choice is sadly obvious:  the #1 tip
you see in Java performance books is "Use StringBuffer to manipulate strings,
not String".

Making String immutable was a very poor design decision, because in people’s
minds, a String object is mutable.  Always was, always will be.  It
would have been much more realistic to call the current String class "ConstString"
and StringBuffer, "String".  At least this naming obeys the principle of
least surprise.