Generics in Java – powerful yet dangerous

I was having a conversation with Jonathan a few days ago about generics in Java. We were dusting off some old code, correcting half remembered bugs (the best kind) and giving it a shiny new coat of paint in the form of java generics and annotations.

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.

OSGi for the Enteprise

Eric Newcomer, CTO of IONA, has an interesting blog on the use of OSGi for developing Enterprise applications. You can read more here. Eric is involved in the OSGi Enterprise Expert Group (EEG).

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.

Applied patterns – parallelism

Doctor Dobbs J0urnal provides an excellent resource for those wishing to research and apply software patterns. In particular Jonathan Erikson’s Pattern Language blog Recently I noticed this post on Patterns for Parallelism about a a research paper on a Functional Parallelism Architectural Pattern for Parallel Programming. The paper is instructive for several reasons. One is that it clearly documents what I’ve described as a macro pattern. It solves a real-world problem which applies to a general computing domain, in this case parallel processing. The paper also references a clear and distinct example, the Single Source Shortest Path searching algorithm also known as Dijkstra’s algorithm. The algorithm is suitable for parallelism because it is “greedy” for resources and it’s also contains sub tasks which can be run concurrently to reduce running time.

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.

Software Archetypes group tasks and philosophy

The Software Archetypes “tech time” group will catalogue and explore software patterns from micro to macro level. Our goal is to promote good software design and to simplify the development of complex software through well documented and robust software patterns and deployment blueprints. This blog is a living journal of our progress and should be kept up to date as our knowledge and thoughts (hopefully) progress.

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.

nice java pattern repository & some thoughts on generics

When looking for java patterns I’m a big believer in knowing a few basic and highly general ones that can be applied in everyday programming. A resource I’ve used in the past is the Design Patterns Java Companion which contains excerpts from the Java book of the same name. The categorisation of pattern types as creational, structural and behavioral is a useful formalism and something we should consider adopting on this blog. Other good points are the layout which consists of

• 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.

Put your Deployment Blueprints here :)

Put your Architectural Patterns here :)

Put your micro patterns here :)

Welcome to the Software Archetypes blog

This is my first post to the software archetypes blog. Part of the TSSG’s “tech time” programme. You can read more about the goals of the blog and the Software Archetypes group here. If you want to recommend any improvements to the blog, its structure or the goals of the group then please do.