techno.blog("Dion")

I went to http://www.jboss.com, and was surprised to see:

Maybe:

a) The Joker is joking again…. and mixed up May with April
b) JDO guys turned out the hibernate easter egg (jboss.com doesn’t use hibernate… I am kidding)
c) JBoss has had so much publicity from the Symposium that the site has been swamped

A nice clean error message either way! :)

Linda DeMichiel was asked if EJB 3.0 would have to be backwards compatible. She immediately said yes.

What would it mean if the backwards compatibility was made “optional”?

• Containers like Spring could support EJB 3 (they are not going to put in support for EJB 2.1 and below!!!)
• Other projects could ramp up to support the more lightweight EJB 3 model
• Other vendors could make a choice on whether they want to support a backwards compatible version. They could even offer two versions!

Would the world be so bad if this was an option? Users would have a choice. If the backwards compatibility means a lot to them, they can choice a vendor which has the optional “Supports 2.1″ checkbox.

The programming model is changing so much, that I think it would be fair to not burden EJB vendors with The Old Ways.

What are the reasons to mandate backwards compatibility?

• Politics: Current EJB vendors have already implemented it, and can use this as an advantage. It keeps the likes of Spring out of the game.
• The usual reasons why we like backwards compatibility

Personally, I wish they made it optional, and we could break out on the new road with EJB 3.

There are certain aspects that are ripe for reuse. There are various levels of reuse of course (totally generic: Log4J, company-reuse: YourCompanyLogger, etc).

A common pattern that you run into, (we use it in aTrack. Ramnivas has it in his book, etc) is that you want to apply some advice, but only to a subset of your code.

The simple way to do this is to use the template pattern:

First, define the abstract aspect which does most of the work, but leave open a scope() pointcut:

public abstract aspect PolicyEnforcement {
  abstract pointcut scope();

  pointcut printing():
    get(* System.out) || get(* System.err) ||
    call(* printStackTrace());

  declare error: scope() && printing():
    ”Our policy enforces the fact that you have to print via our logger”;

  declare warning:
    call(Exception.new()) ||
    call(RuntimeException.new()) &&
    scope():
    ”constructing exception without

We have learned to teach OO programmers to Favour Composition. Why do we do this?

Because inheritance is bad?

Of course not. inheritance is a very powerful design tool at our disposal. If you imagine taking it away from your arsenal (not the damn English football team that I dislike ;) ) you would see people weeping.

When inheritance fits a problem it is elegant and beautiful to behold. If you had to use another technique it would feel like a hack. That is how you will feel if you learn to use AI techniques and they were suddenly taken away.

The problem is that when you use these powerful tools for evil instead of good, then you end up with a grimace. A crazy inheritance hierarchy is an incredibly brittle software design, and will constrain you.

Human nature is to play with the new shiny toy (well for some people. The cynics just complain in the corner). You have to make sure that the toy doesn’t overwhelm you and influence your design decisions. If inheritance doesn’t feel right…. don’t do it!

So, back to Favouring Composition. By planting this seed into a developers mind, they will hopefully think for another nanosecond before they make the Car extend Engine, just because they want to get some of the methods for free.

Thus, my mantra to myself is Favour traditional OO interfaces when designing with AI in my kit bag. With this seed I stop myself from jumping to the oh this would be fun if I wrote an uber-aspect which could do X, Y, and Z!. It doesn’t mean that I won’t use AI techniques when the shoe fits though… and when they DO fit, man are they warm and comfy slippers.

• Realise that Thinking in Aspects is a mind-shift
• Spend some time exploring… and embrace the mind-shift
• Start small: explore with AO in your own personal code, and then follow the adoption curve: starting with testing/tracing/non-production, capture simple policies, low risk / high reward aspects, and on-wards
• Favour OO interfaces (just a check, to make sure you aren’t going to AO for fun :)
• Make your first AO project be a small one, and expect to learn from mistakes
• Understand the power of aspects, and that with power you have to be more responsible.

The ballot results for the JDO 2.0 spec are in.

Although the spec passed, there was some significant “No Votes” from IBM, BEA, and Oracle.

They made comments to the effect of:

“There is no room for JDO anymore. EJB 3 is your new persistence model”

Personally, I just want a nice transparent persistence standard. I guess if EJB 3 does a better job than JDO does…. good for them. However, logically, it seems to make more sense that:

JDO: Defines a specification for transparent persistence.
EJB: Define enterprise cross-cutting concerns, using existing specifications where possible.

I think everyone would have been better served in this model. The JDO model allows for persistence without EJB. One of the use cases there is JDO on devices. Are we going to start to see EJB for mobile phones?

JDO has a lot of smart people, who have spent a lot of time on these problems. It is almost a little arrogant to say “we don’t need you”. Why not involve some of these people in the process?

Oh well, time will show us the story. As long as we actually get transparent persistence!

Tom Malaher has brought up Zoe in Google your Email.

Zoe is a really cool app that uses Lucene to index the hell out of your email. And, all on the client side… without Google Ads bothering you.

Zoe (and GMail) are hopefully the start of the New Email Clients. It is time for a revolution in email. Folders just don’t cut it.

I talked about this back in MetaMail: What I want in my email client.

Now if you put together something like Zoe + something like Flow… hmmm….

Brian McCallister has written a Defense of the Wheel.

I agree with him. If you worked for Michelin you would laugh heartily if someone told you not to reinvent the wheel wouldn’t you :) We have been reinventing the wheel as a race for a LONG time. It is a natural thing to do. It is evolution.

Although we want people to innovate, and come up with new and better wheels (for given tasks) we don’t want people to reinvent the same wheel as then we just have choice without anything to gain.

So, writing another web framework that is kinda like Struts but does 1 thing different is probably reinventing the wheel. Take one of the other frameworks and make it better.

With Brian’s ObjectFilter he is exploring a new way to do something that can kinda be done now…. but the method is much more elegant. Nice work Brian…

Let’s keep inventing better wheels :)

TMC asked the community to name the movers and shakers in enterprise Java.

Then a lot of discussions ensued on who fits where into a deck of cards, where each suite has a different meaning (see below). It was kinda fun to do, and should of course be taken with a pinch of salt (whether you are the 4 or 5 of clubs doesn’t mean anything :) ).

One fun part is that the jokers are Hani and Marc Fleury. Playing cards with this deck will be fun!

TMC Announces Who’s Who in Enterprise Java 2004

TMC announced today the Who’s Who in Enterprise Java 2004 award winners. Published as a deck of cards, individuals are recognized and honoured under the categories of Contribution (Hearts), Power & Influence (Spades), Entrepreneurship (Diamonds), Pot Pourri (Clubs) and Jokers. A lot of known and unknown deserving people are recognized, including a few surprises.

Marc Fleury said the following in an interview at InfoWorld:

When is EJB 3.0 due out and what