Discussions

News: Announcing Macker Pattern Based Rule Checker

  1. Announcing Macker Pattern Based Rule Checker (11 messages)

    Macker is an architectural rule checking utility for Java. It's meant to model the architectural ideals programmers always dream up for their projects, and then break. It is not a lint checker -- it operates on a more global, more logical level, focusing on class dependencies rather than source code formatting. Macker has no default set of rules; it's flexible, and writing a rules file is part of the development process for each unique project. You can tailor a rules file to suit a specific project's structure, or write some general "good practice" rules for your code. Macker typically runs as an Ant task, but can also be invoked with a shell script.

    Macker is particularly useful for J2EE projects, which are generally split into layers with very specific roles and relationships. So, for example, you could prevent any code except your data access objects from accessing database APIs.

    Version 0.4 adds many new features -- most notably filter-based patterns, rule severity levels, a new XML reporting feature -- and several important bug fixes.

    Macker home page

    Changes in 0.4

    Download

    Threaded Messages (11)

  2. And I should add...[ Go to top ]

    ...the project has some open tasks and is looking for developers!
  3. Automated Architecture Validation[ Go to top ]

    Hey Paul,

    I've had several experiences with automated checking that dependencies are conform intentions. I think that's worth a lot when you're working with a bigger team or with less experienced developers.

    I haven't checked your latest version but I think it's a very good idea as a whole.

    groeten,
    Joost
  4. I have been thinking that a tool like this makes sense in very large code bases. I think where it gets interesting is where you move the line separating the external rules from the rules that are part of the grammar itself. For example, you could use a rule system on top of a simple procedural language instead of an object-oriented language, to make the whole structure more flexible. I also think that it would be useful to span multiple languages, so you could keep, say, Struts Actions and HTML forms in synch. Also, syntactic and stylistic rules should be very important, e.g. constants should be in upper case, no hard-coded strings, and so on. I hope this project takes off ...
  5. I think where it gets interesting is where you move the line separating

    > the external rules from the rules that are part of the grammar itself.

    Guglielmo -- I'm not quite sure what you mean by this. Could you explain a little more?

    > I also think that it would be useful to span multiple languages, so you
    > could keep, say, Struts Actions and HTML forms in synch.

    That's a very interesting idea, but one I'm keeping it off the plate until after Macker 1.0 -- I want to get basic Java rules checking mature first.

    > Also, syntactic and stylistic rules should be very important, e.g.
    > constants should be in upper case, no hard-coded strings, and so on.

    That sort of functionality is explicitly out of scope -- it's a fairly different problem, and tools like Checkstyle and JCSC solve it well already.

    Macker's rule language will increasingly be robust and fine-grained enough to express things that are really formatting / style rules, but that's not Macker's primary purpose.

    > I hope this project takes off ...

    Thanks! I encourage you to try it out.
  6. I think where it gets interesting is where you move the line separating

    > > the external rules from the rules that are part of the grammar itself.
    >
    > Guglielmo -- I'm not quite sure what you mean by this. Could you explain a little more?

    I mean that the compiler enforces certain rules for you, for example that a class cannot extend two other classes. Now the question arises, what do these grammatical rules have that the "external" rules do not? I think from the point of view of the developer they are the same. But then would it make sense to have just one set of rules? You see where I am going with this?

    > > I also think that it would be useful to span multiple languages, so you
    > > could keep, say, Struts Actions and HTML forms in synch.
    >
    > That's a very interesting idea, but one I'm keeping it off the plate until after Macker 1.0 -- I want to get basic Java rules checking mature first.

    Probably a good strategy.

    > > Also, syntactic and stylistic rules should be very important, e.g.
    > > constants should be in upper case, no hard-coded strings, and so on.
    >
    > That sort of functionality is explicitly out of scope -- it's a fairly different problem, and tools like Checkstyle and JCSC solve it well already.

    See, to me they are no different. To me you are specifying constraints on an object tree, and there are multiple parallel representations of the same tree. The first tree is the list of tokens - that's what you would use to enforce syntactic rules, the second tree is the abstract syntax tree. Then you could also add other trees that are higher-level representations. For example, for complicated patterns that's what you need. Or for an ejb, for example, you could have an ejb node which includes several classes. That's why to me the syntax rules and the grammar rules are on the same footing.

    > > I hope this project takes off ...
    >
    > Thanks! I encourage you to try it out.

    I will if I get a chance.

    Guglielmo
  7. Moving Macker into the language[ Go to top ]

    I think where it gets interesting is where you move the line separating

    > > the external rules from the rules that are part of the grammar itself.
    >
    > Could you explain a little more?
    >
    > I mean that the compiler enforces certain rules for you, for example that
    > a class cannot extend two other classes. Now the question arises, what do
    > these grammatical rules have that the "external" rules do not? I think from
    > the point of view of the developer they are the same. But then would it make
    > sense to have just one set of rules? You see where I am going with this?

    I think I do see what you're saying now -- by "external", you mean "external to the language itself." I think I can answer your question now:

    There's an important difference between rules which are an inherent part of the language, like "a class can extend at most one other class", and classes that are specific to a particular piece of code, like "this field is private" or "only classes in this package may access database APIs". Unless you're wandering into the interesting but very un-Java world of CLOS-like dynamic redifinition of the language, that distinction between rules of the language and rules of the project should remain strong.

    However, the distinction between different kinds of project-specific rules -- "this field is private" and "only classes in this package may access database APIs" -- is fuzzier, and I can certainly see the possibility of extending the set of constraint mechanisms built into the language to allow more large-scale, more cross-cutting rules. I'm not sure Macker's approach would be well-suited for inclusion in the language -- Macker is aware of project / codebase boundaries which don't necessarily exist from the language's point of view -- but it's a fun and promising thought experiemtn.

    Still, of course, all of that is just idle pontification until Macker achieves some kind of completeness in its current role.

    > > > Also, syntactic and stylistic rules should be very important
    > >
    > > That sort of functionality is explicitly out of scope -- it's a fairly
    > > different problem, and tools like Checkstyle and JCSC solve it well already.
    >
    > See, to me they are no different. To me you are specifying constraints on
    > an object tree, and there are multiple parallel representations of the
    > same tree. The first tree is the list of tokens - that's what you would use
    > to enforce syntactic rules, the second tree is the abstract syntax tree.

    Well, that's a very ambitious perspective, and fun: you gain the ability to contrain almost anything in any parsable language. But in doing that, you lose a lot of the simplicity of narrowing the constraints and kinds of things you're constraining.

    Macker is intentionally very limited. Its rules language is not a full programming language -- it's a very simple declarative language, and it can get away with being so simple because its purpose is so narrowly defined.

    Having to deal with arbitrary constraints on arbitrary parse trees would lead a rules language more like, say, XSLT: very specialized to a particular category of data structure, but still an arbitrarily complex programming language. That kind of language would be a very fun thing to write, but it's much more ambitious than Macker, which is aiming for more immediate, pragmatic utility.
  8. Moving Macker into the language[ Go to top ]

    Having to deal with arbitrary constraints on arbitrary parse trees would lead a rules language more like, say, XSLT: very specialized to a particular category of data structure, but still an arbitrarily complex programming language. That kind of language would be a very fun thing to write, but it's much more ambitious than Macker, which is aiming for more immediate, pragmatic utility.


    I congratulate you on a very good strategy. I would also like to add, however, that if the tree is simple, then the rules are simple. Therefore it should be possible to get good usability by combining a transformation with a set of simple rules, but it's just a hunch ..

    I will definitely check out your rules when I get a chance.
  9. Paul,

    How does this compare with AspectJ in terms policy enforcement?
  10. AspectJ compared with Macker?[ Go to top ]

    How does this compare with AspectJ in terms policy enforcement?


    George -- I'm afraid I have only a very basic understanding of AspectJ. The fundamental difference, of course, is that Macker is a static analysis tool and AspectJ is actually a compiler. What do you mean by "policy enforcement"? Are you talking about runtime security, or does the AspectJ have facilities for specifying which classes may depend on which?
  11. Beaten to the punch![ Go to top ]

    Macked looks like an interesting project.

    I'm just about to release a tool that is very similar: aDarwin (I took my inspiration from iDarwin a Reliable-Systems project).

    Maybe we can compare and contrast sometime.

    Stacy at digitalcompulsion.com
  12. Typotastic[ Go to top ]

    Oops I mean Macker, no offense!