Macker is a Java developers' utility which checks classes against user-defined structural rules. It's meant to model the architectural ideals programmers always dream up for their projects, and then break -- it helps keep code clean and consistent. You can use it to check general "good practice" rules, and you can also tailor a rules file to suit a specific project's structure.
Macker operates on compiled Java classes. It usually runs in your build process just after javac, but you could also make it part of your unit testing or packaging process if you like. It is available as an Ant task and as a command-line utility, both of which read an XML rules file format. It also has some Java APIs which you can use directly, though they will not be guaranteed stable until the 1.0 release.
Macker is a nice sanity check to keep your code matching all those boxes and arrows on the whiteboard, and prevent the architectural theory from unraveling in practice. It gives developers immediate feedback when they break conventions, and drives little mistakes and big architectural issues out into the open. When architectural rules don't work, the problem prompts a group discussion instead of an obscure hack.
If you're designing for a project with a large number of developers, Macker is a great way to keep architectural principles from being diluted after release in the wild. All those people who weren't in on that discussion at the whiteboard, and thus don't necessarily have the whole picture in their head, will get a helpful nudge in the right direction when they go astray.
Macker is not for class security. Java's native access modifiers provide guarantees about information visibility and state integrity -- private members are guaranteed to be private, unless a class chooses to expose them. Java can do this because "private" is not only enforced by the compiler, but by the JVM itself. Because Macker is not part of the Java language, it can provide no such guarantees. It is a sanity check, not a security check. (You might use Macker as part of a security audit process, but that's a different question.)
Macker is not a substitute for first-class Java language constructs like access control and strong typing. A good object model should use the language to represent and reinforce its architectural intent, Macker or no.
Macker is not meant to enforce nit-picky code formatting conventions, and obviously can't enforce aesthetic standards like "use conceptually clear names".
Finally, Macker isn't good if you don't want to specify your own architectural rules. It is not a lint checker, and does not proscribe any general rules for everyone; rather, it helps you stay consistent with the particular rules you came up with for your project. You might eventually build up a "general practices" rules file which you use across projects, but that's up to you!
Macker allows you to specify broad access rules that Java's native access modifiers can't. The current version supports class- and package-level access rules, such as:
(All of these are all just examples. Macker doesn't check anything by default; it's up to you to write rules to fit what you're doing.)
Future versions will support more sophisticated matching class matching, existence/nonexistence rules in addition to access rules, and possibly rules applying at the method as well the class level. This would allow rules such as:
There are several lint checkers and style checkers available for Java, such as Checkstyle and JCSC, which verify that code adheres to formatting, naming, and style conventions. (The nascent project TestPattern also seems to belong in this category.) These projects also sometimes flag potential errors (such as empty catch blocks), a task which PMD and Jlint are specially designed for.
Macker is, for the most part, complementary to these tools: they operate on source code, and deal with line-by-line implementation details, typically in a peephole fashion; Macker operates on compiled classes, taken all at once, and focuses on large-scale structure. Macker can't catch misnamed local variables, misplaced braces, or empty catch blocks; conversely, these other tools aren't very good for expressing and checking architecture-level code structure. Putting it differently, these other tools live in the realm of the Java coding conventions, and Macker lives in the realm of the Java Blueprints. This is why Macker's rules files must be entirely project-specific -- there is no single "Java architecture".
At the time of this writing (August 2003), the only other projects we're aware of that fits the same niche as Macker are aDarwin and PatternTesting. ADarwin's intent sounds similar, if not identical. It is a younger project, but quite promising. PatternTesting's online documentation is a bit thin -- it appears to be built on top of AspectJ, and use aspects to declare rules. Intriguing!
Macker is quite stable, and reasonably bug-free. It's certainly suitable for real-world use.
The reason for the pre-1.0 version number is that there are still some fairly serious feature gaps. For example, you can only currently apply access rules to classes, and not methods.
So basically, you'll find that Macker doesn't do everything you want -- but what it does do, it does well.
Macker is available under the GPL. This license allows you to freely use and redistribute Macker, and to bundle it with other software.
If you make changes to Macker or extend it, and you choose to distribute those changes, you must license them under the GPL. It would be marvelous if you submit your patches back to the Macker project for possible inclusion in future versions.
You can download binaries, source code, and this documentation from the Macker download page, hosted by the good folks at Sourceforge.
See the guide for the juicy details.
Here's a few to get you started. You'll also find some sprinkled throughout the user's guide.
If you have other examples you'd like share with the world, send them along!
Subscribe to the user mailing list. It's not terribly high-traffic, and questions generally get answered quickly.
Yes please! There are always open tasks in need of developers. It's also important not to underestimate the importance of bug reports and feature suggestions from users -- if you don't tell us, we won't know. Finally, Macker needs evangelists -- so mention it to your programmer friends, work it into your own projects, write an article on it, spread the word!
It's a reference to Money Puzzle Exchanger, a Neo-Geo arcade game of the two-player puzzle variety, not unlike Bust-a-Move, Super Puzzle Fighter, and Magic Drop. (It is, in the author's opinion, the finest game in the genre.) Money Puzzle Exchanger has that strange mixture of cuteness and inscrutability that the Japanese have raised to a fine art -- it features cartoon characters with names like "Debtmiser", "Mightdealer", and "Eldylabor".
One of them is "Macker", a rather overexcited fellow in an absurd cape, boots, jumpsuit, and what may be a lava-proof space helmet of some kind:
Observe on the right his reaction to defeating Everyworker (a far more mature character, who is upset that I set her up to lose just for some stupid screenshot) -- Macker is an exceptionally arrogant fellow, no doubt. But clearly something more than his big ego is eating at him. Macker, shall we say, has issues.
Why, you may wonder, why does Macker get so mad?
Well, now we know the answer: Macker is mad because you violated your architectural rules. Aren't you glad that a psychologically unstable anime character cares so much about your code?
The exact cause and nature of Macker's apparent dental problem remain unknown as of this writing.
Thanks to Victor for suggesting the name.
Paul Cantrell, with some help. Feel free to contact me with questions, comments, ideas, bug reports, puns, etc.