Going to JavaPolis – err – Devoxx 2010 :-)

We just got notification that our BoF regarding the jpatterns.org annotations has been accepted for Devoxx 2010 in Belgium, the largest Java developers conference in Europe.

At the moment we’ve put Michael Hunger and Heinz Kabutz down as speakers, but please let us know if you are in the area and would also like to join us.

Heinz

Inner Annotation Attributes

jonnybbb made a suggestion that we rather use attributes for the participants and comments.  I’ve done this for all of the annotations and inner annotations, so instead of

@CompositePattern.Component
@PatternParticipants({DistributionList.class, Person.class})
public abstract class Contact {
  public abstract void sendMail(String msg);
  public void add(Contact contact) {}
  public void remove(Contact contact) {}
}

We can now do the following:

@CompositePattern.Component(participants = {
    DistributionList.class, Person.class})
public abstract class Contact {
  public abstract void sendMail(String msg);
  public void add(Contact contact) {}
  public void remove(Contact contact) {}
}

That is even better, because then users will see the options available with autocompletion. Lots of duplication inside the annotations, but it is not our fault that you cannot inherit annotations 🙁

Heinz

jpatterns

We have tried different approaches to specifying the patterns. The current favorite is to use inner annotations for specifying the roles.

So, instead of our earlier approach:

@CompositePattern(role = CompositeRole.COMPONENT, participants =
  {DistributionList.class, Person.class})
public abstract class Contact {
  public abstract void sendMail(String msg);
  public void add(Contact contact) {}
  public void remove(Contact contact) {}
}

We want to do the following:

@CompositePattern.Component
@PatternParticipants({DistributionList.class, Person.class})
public abstract class Contact {
  public abstract void sendMail(String msg);
  public void add(Contact contact) {}
  public void remove(Contact contact) {}
}

I think that is easier to read and understand.

Would love to hear your opinions on this.

Heinz

Welcome to jpatterns.org

Design Patterns are typically encoded into Java code in an ad-hoc fashion.  They are either embedded into the names of the classes or written into the Javadocs.  Unfortunately it is impossible to accurately determine a pattern based solely on the class structure without knowing the intent of the code author.

JPatterns is a collection of annotations that make it easy to communicate the use of (Design)Patterns within your code to your fellow developers and your future self.  We follow the KISS principle by using reasonable defaults for the annotation attributes.  Thus, if you are writing a composite, you can simply specify:

@CompositePattern
public abstract class Contact {
  public abstract void sendMail(String msg);
  public void add(Contact contact) {}
  public void remove(Contact contact) {}
}

Or, if you wanted to, you could also be more explicit, for example

@CompositePattern(role = CompositeRole.COMPONENT,
 participants = {DistributionList.class, Person.class})
public abstract class Contact {
  public abstract void sendMail(String msg);
  public void add(Contact contact) {}
  public void remove(Contact contact) {}
}

Please let us know if you would like to be part of this project by leaving a comment on this website.

Please access the repository here: http://github.com/jexp/jpatterns

Michael Hunger
Heinz Kabutz