ArchJava

My first two stream-of-consciousness reactions are "why bother?" and "would any real team ever use this?"

Integrating ArchJava into the Java language does have the benefit of keeping documentation and diagrams in sync with the code, which always seems to be a problem with code comments and formal docs. However, I know there are tools out there that can look at vanilla source code and generate a visualization of your dependencies and communication structure without the need to use custom language extensions. The paper says the following: "Automated tools could have gathered some of this connectivity information from the original Java program. However, these tools would require sophisticated alias analysis to support the level of reasoning about component instances that is provided by ArchJava’s communication integrity." Either I'm missing what they're saying, or the tools that I already use have "sophisticated alias analysis" because they do a great job doing everything ArchJava does and more from an analysis standpoint.

As far as restricting communication between components, can't you achieve the exact same functionality as the "out" keyword my making sure you make all methods private except those that are intended to be used by other components? I must be missing something, because that is very basic design to me. I think their reasoning is sound, and teams would think more about communication between components when initially connecting them because it is a more burdensome process with ArchJava. However, I can easily see the in/out/port trio being abused.

I also find it hard to believe that any team outside of academia would ever want to use this. Would you want to develop an enterprise application using a non-standard compiler and (maybe) JVM? I'm not going to be the architect to approve that.

I think the paper lost some credibility with me when they proposed glaringly obvious hypotheses such as "refactoring is easier when done in small chunks" and "if the implemented architecture doesn't match the desired architecture, you'll have to refactor it if you want it to match."

I don't know what problems of the "Making Memories" project or any other project this would solve that couldn't be done easily with existing tool sets, decent team standards, and a review process. I like being able to automatically prevent and detect code smells such as the Law of Demeter violations (one of my pet peeves), but I don't like the hoops that ArchJava makes you jump through nor do I trust that the tool could work without reviews and standards that the teams should have anyway. Maybe I feel this way because the teams I work on are always less than ten developers, but I still think that there is the tooling out there to support the same process without the need to change the language that developers are already comfortable with.