I’ll discuss annotations in later posts but our conversations hightlighted what I’ve discovered is an all too common misunderstanding about subtyping with java generics. Just to be very clear, I believe java generics are a very very good thing. However, they require a bit of caution when applying to legacy code. SUN already have an excellent guide to generics which is part of their Java Tutorial

However, I’ll just draw the readers attention to the two most common errors I’ve seen. Both relate to over-specialisation of a class following the application of generics.

The Java tutorial cites a simple operation on collections such as the outputting of a list.

void printCollection(Collection c) {
Iterator i = c.iterator();
for (k = 0; k < c.size(); k++) {
System.out.println(i.next());
}
}

And a naive attempt at writing it using generics (and the new for loop syntax):

void printCollection(Collection<Object> c) {
for (Object e : c) {
System.out.println(e);
}
}

This looks really nice but the problem is that the printCollection now must be an Object and ONLY an Object. It’s very unlikely that was what was intended by the original author. This seems to be the first and most common mistake that every Java programmer who starts experimenting with generics makes. Yet I can see how this kind of thing could easily pass a unit test, one which uses a dummy java.lang.Object… ooops
Which leads us to non-trivial statements like the following.


public static <T extends Object & Comparable>
T max(Collection coll)


Which means Max is calculated on a collection where each element extends T and returns a value which is of type T that extends type java.lang.Object (for backwards compatibility) and is comparable in itself or is derived from a comparable type
So generic programming actually requires more careful thoughts and explicit statement about type-safety than non-generic.
I’m not actually sure this is an altogether good thing as it’s arguably impeding the adoption of generics, irregardless of their uses in the creation of extremely reusable and modular patterns.

Many OSGi experts make a convincing case for implementing SOA using OSGi due to it’s well thought out and integrated service publish, discovery and bind mechanisms together with an explicit lifecycle model which incorporates service updates/patching. All in line with broader SOA objectives as defined by the Open SOA Collaboration

The EEG’s areas of interest include:

• scaling including multi-container and multi-process environments
• Language bindings for enterprise services including, but not limited to the Java language
• distributed and/or federated service model:
  • within multiple Service Platforms
  • with external, heterogeneous systems
• requirements for extensions to the OSGi publish/find/bind service model
• bundle dependencies profiling and matching
• enterprise-class life-cycle and configuration management
  • from initial provisioning
  • through software and asset management, patching, etc.
  • focused on desktops, laptops, and servers
  • including reliability, availability, serviceability concerns

It will be interesting to see whether the OSGi model is adopted by SOA implementors and what cross-pollination will occur between it and the WS* architects.

The well known routing algorithm OSPF (Open Shortest Path First) is the most common implementation of this algorithm in computer science. The discussed “layer” pattern enabling overlapping operations which are run for effect rather than value. i.e. They’re effect can be calculated in such a way that it is not necessary to wait for the completion of an earlier layer. What I really like about this example is that it achieves the following objectives of any good macro pattern.

1. It solves a distinct theoretical or abstract problem
2. It describes the solution both graphically and through pseudo-code. It’s not tied to the implementation specifics of any particular programming language.
3. It clearly explains the benefits and drawbacks regarding the application of the pattern.
4. It references supporting algorithmic research and design.
5. It outlines real-world problems that the problem can be applied to.

These should be patterns which are deemed interesting or useful to group members or ones that meet direct requirements from projects within the TSSG. The group activities can be decomposed into the following tasks.

• Identification of design patterns and deployment blueprints across existing TSSG projects. Initially we’ll focus on blueprints for scalability, fault-tolerance and security.
• Cataloguing existing software patterns which are being used successfully by TSSG projects.
• Identifying new software patterns and the latest thinking in software design and pattern application across a range of languages and methodologies.
• Discussions with tech leads and project team members to discover barriers preventing the successful adoption of design patterns and blueprints on projects.
• Dissemination of design pattern best-practice through the Software Archetypes blog
• Liaising with new projects to determine functional and non-functional requirements that could be met using design patterns and blueprints… In particular scalability, fault-tolerance and security issues.
• Liaising with the autonomics group to determine if concise blueprints or patterns can be distilled from the Foundations Of Autonomics Programme.

That should be enough to get started . Not all these tasks need to be addressed initially so pick and choose the things that interest you. Equally if you have another suggestion regarding group activities and philosophy that you think is relevant then don’t hesitate to post your thoughts.

• Pattern name and natural language description
• UML diagram(s) representing the pattern
• The code required to realise the pattern
• Code demonstrating sample usage

In other words the whole process should be idiot proof, nearly immune to tired eyes and weary brains that afflict the programmer pushing for an ambitious deadline.

However, one weakness of much of the java design pattern literature is the relatively late introduction of Generic Programming into the Java Language. For those who haven’t programmed Java in a while I recommend reading this tutorial from SUN. It’s worth remembering that NOT ALL Java projects will use jdk 1.5 and therefore some projects will require patterns which don’t use generics. Sometimes a hybrid approach is necessary where a template pattern is permit a lightweight form of generic programming for older JDK’s.