You're really quoting me out of context here…

I was specifically replying to a comment which complained about Roo generating 3 aspect classes (basically the ITDs) for your main Java class, and this being comparable to EJB 2.1 programming, or writing lots and lots of XML. My main point was that you really don't have to worry about creating these ITDs yourself, or having them impact your code at the code level (i.e. having to extend special base classes, implement special interfaces, or tie yourself to a container, etc. Roo will create (and remove) the helper ITDs automatically… This is fundamentally different than EJB 2.1, which has a huge impact on your code and process in a number of ways, and is fundamentally different to writing and managing lots of XML.

That said, w/respect to having to think about or understand the code in the ITDs, I do think the Roo approach required a fundamentally different level of understanding and involvement with that code, since you don't have to write it. It's one thing to add a field to your entity, and then have Roo automatically create or modify an aspect to add persistence for that field, and then be easily able to go in and see the generated code (and even do push down refactoring if you want to, to bring it into your code), vs. quite another level of understanding and involvement to go the traditional route of having to write the persistence code yourself from scratch…

Colin

"The aspects are generated for you and you don't really have to think or know about them to any real extent,…"

I heartily disagree. If the generated stuff is running or supporting the app, I have to understand how it works because, inevitably, something will go wrong or I will want it to generate differently, etc. It doesn't matter how much stuff is generated for me. If I don't understand it, I can't support it.

I have seen this time and time again with every wiz-bang tool that comes down the pike. That's just as true with even Spring itself. You have to understand the concept of dependency-injection and how it works before you can use Spring effectively (especially when it comes to unit testing).

In fact, I think that requirement is the fundamental driver behind Roo. The Java development landscape has been greatly enriched by powerful frameworks like Spring, Hibernate, JSF, etc. But with each gain has also come a significant increase in complexity. So now, Roo comes along and tries to hide all that and jump start the creation of an app, using all these tools the "right" way. Kinda ironic I think.

Don't get me wrong. I applaud your efforts and this looks like a great tool to me.

Just don't oversell it. This tool may help by letting us ease our way into the massive complexity of all the frameworks involved. But it surely does not relieve us from having to deeply understand them all eventually.

* The importance of separation of concerns is heavily reflected in formal computer science training as well as in practice. It's why we strive for specific layering techniques and concepts like high cohesion, MVC, the decorator pattern and AOP. There is far less emphasis on "cross cutting concerns", as they're simply a fact we need to deal with (like persistence, user interfaces etc) as opposed to some architectural concept we should be pursuing.

* If cross-cutting behavior were the only objective of AOP, we would not see mix-ins, inter type declarations (ITDs) or alike provided by AOP implementations. These concepts exist because the development community has identified merit in the concept of introducing members to types which did not declare those members in the traditional compilation unit for those types. One compelling benefit of mix-ins (ITDs) is separation of concerns.

I referred to cross-cutting behavior in my original reply because that's what most people associate with AOP and it is where its benefit of separation of concerns has been most visibly proven. If you try the tool you will see it easily supports you writing your own members in your own compilation units just as you always have, and it will automatically and intelligently not generate members in ITDs for manually-coded members. You will also see the tool does not do anything unless you ask it to via an annotation or UI directive, and even then it will not act unless the metadata model indicates it should act. It will automatically monitor your environment and update ITDs (and other files) as appropriate in response to changes.

Roo is one of those things you need to try out to see that it really does not get in your way. It's fine if you don't want to try it out, but if you don't try it out you should at least qualify your remarks accordingly. And if you did try it out and ran into an issue, please let me know what happened so I can clarify whether it is a design constraint or simply a bug that we will fix (remember Roo is only at alpha 2 stage right now).

In closing I again note we could have put all these members directly into .java compilation units if we wanted to. We simply think it's a bad idea as this is not achieving separation of concerns. People who disagree can still use Roo and move the members into their .java compilation units. But they sacrifice the benefits of separation of concerns and will have higher maintenance costs accordingly.