UML, the Template Class and Java

One problem you often see when dealing with UML is that some developers don’t get the idea that what you see in class diagram should translate directly into code they draw a class diagram and write some code and neither bare any resemblance to each other. This, and other forthcoming blogs in the series, demonstrate the link between diagrams and code.

This blog demonstrates how to draw a template class in UML followed by its equivalent Java code and looking at it you'll notice that the Java code is all about generics. I guess that's because UML's template class idea stems from C++'s template classes, which are similar to, but not a direct equivalent of Java's generics.

EJB3 Transaction Annotation

This blog documents the EJB3 transaction annotations and was written because I had to add a transaction annotation to an EJB recently and the javadoc for JEE 5 didn’t document what the TransactionAttributeType values do; some are obvious if you’ve done this before, but I'm not psychic.

Message Driven Bean Annotations for EJB3

The other day, I blogged about the name and mappedName attributes of @Stateless, @Stateful and @MessageDriven annotations of EJB3.

In writing that blog, it occurred to me that it’s very hard to find information on which attributes are available. In the good ol’ days of EJB 2.x, all you had to do was to look at the appropriate EJB schema file and you knew which XML element and attributes did what.

The Observer Pattern

Having written two blogs that mentioned the Observer pattern, I thought that I’d talk about it more formally, mainly because the Wikipedia entry for this pattern is a bit rubbish: the Java example given doesn’t implement the class diagram shown and uses the flawed Observer, Observable classes instead. Looking back at my GOF Design Patterns book, the actual pattern should be something like this:

Using EJB3 Annotations with Weblogic 10.3 / 11g

It seems to me that BEA and now Oracle are usually behind the curve when it comes to implementing the latest JEE specifications and often interpret things rather differently to the guys working on the Glassfish reference implementation.

Implementing the JDK's Observer Pattern

Yesterday’s blog talked about the ActionListener event handler's implementation of the Observer pattern that is woven throughout Java’s Swing classes. The JDK duplicates this pattern in an implementation with classes called Observer and Observable.

Events and the ActionListener

The ActionListener event handlers are an implementation of the Observer pattern that is woven throughout Java’s Swing classes. It’s used by buttons to inform their clients that they’ve been pushed, it’s used by menu items to tell the application that a selection has been made, by the JFileChooser to select files and by many other classes.

The Three Laws of Test Driven Development

I’ve mentioned Test Driven Development several times in this blog, but haven’t yet got around to defining its three principle rules. These were, I think, first documented by Bob Martin in IEEE Computer Society Journal of May/June 2007. To summarise, the three rules are:

Primitive Wrapper Classes and Their Factory Methods

The java SDK primitive wrapper classes such as Integer, Boolean and Long come with a whole bunch of often ignored factory methods that can be used to improve performance. Indeed, the best advice when converting a "true" or "false" is to use

      val = Boolean.valueOf("false");

rather than

Using the Builder Pattern to Construct Thread-Safe Objects

A couple of days ago my blog described the benefits of creating immutable POJOs in order to make your programs more thread-safe. Today’s blog builds on that idea, by demonstrating the use of the Builder pattern to construct your POJO’s. It’s strange that I haven’t discussed this before as it’s one of my favourites. You can find it in more detail in Joshua Bloch’s Effective Java Second Edition - page 14.

The Telescoping Constructor (Anti)Pattern

The Telescoping Constructor is an example of a pattern that borders on an anti-pattern that is all too often used in projects even though there are better alternatives availble. In this pattern, your POJO has numerous constructors each taking a different number of parameters that, if the class has been written correctly, delegate to a default constructor.

Thread-Safe Immutable Objects

Threading problems are the most weird and difficult bugs to fix, mainly because they’re so hard to reproduce. You can mitigate some of these problem by designing thread-safe code, which isn’t so hard as you think.

The code below is an example of a thread-safe technique that's for synchronising the update of instance variables without the need for language specific locking and mutexes. The big idea is that we tie two or more instance variables together in a bean. The fields are final and obey the Java rules of only being updated table during either static initialisation or when the constructor is called.

Generating Message and Correlation Identifiers

SOA messages often need to include, as part of their schema, some kind of unique identifier. This is usually called ‘message identifier’ or even ‘correlation identifier’. The idea here is that when a calling service receives a reply from your service, it’ll know what your service is talking about. This is especially helpful when the call is asynchronous.

String Formatting

Crusty old Java hacks, myself included, use the StringBuffer class (or StringBuilder) to stitch together strings, but Java 5 added String formatting classes to the API to and a ‘C’ style printf(...) to the System.out class to make life easier.

These newer classes are seemingly often under-used, but pretty straight forward...

Are finalize() Methods Useful?

Under normal circumstances, the finalize method is not of much use when programming everyday java code. Indeed, Joshua Bloch states, in his book Effective Java, that "finalizers are unpredictable, often dangerous, and generally unnecessary"; given this view, it's not surprising that the section of the book I'm referring to is called 'Item 6: Avoid finalizers' (see Page 20).

Creating a Spring Web Service Using Version 2.0.1.RELEASE

I thought that I’d write a Web Service using the Spring Web Services product. This is described as a Contract-First web service; however, the guys at Spring have made life a little easier for us in that the product can dynamically create a WDSL file, which is a feature that we’ll be using.

The scenario for this example is of a wine search service, in which the client sends a request containing a country name and gets back a list of wines produced by that country. For the purposes of this example, I already have a business service POJO and that I’ll be injecting it into my web service code.

Web Service Design: Contract-First or Contract-Last?

Web service design seems to come in two flavours contract-first and contract-last. Contract-first starts with designing the XML schema / WSDL and then creating the Java interface based upon the schema.

Contract-last takes an existing Java interface and from that, creates your web service. On reflection, you’d think that this meant create a schema contract, but generally it seems to mean getting hold of some tool that will take a Java interface as an input and deliver a WSDL as an output.

An Easy Way to Build a Schema Using XMLBeans inst2xsd

I know that I’ve mentioned this tool before, but I was too brief. This blog rectifies that by demonstrating how easy it is to build your self a schema using a little sample XML and inst2xsd, which is free.

SAXBuilder ClassNotFoundException When Creating a SAX Parser.

I was recently using JDom to parse some XML.

      InputStream is = new FileInputStream(fileName);

      SAXBuilder builder = new SAXBuilder();
      retVal = builder.build(is);

Everything was pretty straight forward untill the code ran, when the build() method threw a ClassNotFoundException

How to Schema Validate XML Using SAX

This blog builds on my Checking for Well-Formed XML blog creating a class that can validate XML messages against their schemas by using extra features available in the SAX parser.

This example uses JDom, as part of its interface, but you could use any XML API, such as XmlBeans, or even pass in a String.

The steps required to create a schema validator class are:

inst2xsd and Other Useful Tools

No matter how much you think you know about a tool, pattern or subject, there’s always something useful that pops up from time to time. I’ve been using XmlBeans for a number of years and only found out about inst2xsd the other day and all this time I’ve been writing XML schemata by hand.

This little blog is just a quick reminder that Xmlbeans provides useful tools as well as a useful API by demonstrating how to use inst2xsd.

The simplest way of using inst2xsd is to type:

inst2xsd /filename.xsd

This will produce a schema file called schema0.xsd whose contents won't be perfect, which means that you'll need to fiddle around with it tailoring it to meet your exact needs.

For more information on inst2xsd see inst2xsd on the xmlbeans tools page.

Breaking the Single Responsibility Principal

One of the most important programming principals is the Single Responsibility Principal (SRP), which states that an object should have one, and one only, reason to change its state.

weblogic.xml Versions in your Webapp

Using the wrong version of weblogic.xml in your Weblogic webapp causes eclipse to shout about a whole bunch of errors. For example, using the following schemata:

<wls:weblogic-web-app xmlns:wls="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/920/weblogic-web-app.xsd">

causes the following error:

Unit Tests and the FIRST Acronym

ObjectMentor came up with a really good acronym to describe Unit test, it’s FIRST and it describes all the qualities of a good test.

Java Primitive Sizes

The sizes of Java primitives are:

Type	Min Value	Max Value	Bits
byte	-128	127	8
char	0	65535	16
short	-32768	32767	16
int	-2147483648	2147483647	32
long	-9223372036854775808	9223372036854775807	64

Generic Factory Class - Sample

Previously I’ve talked about generic classes and generic methods. This blog combines the two and demonstrates how to write a generic factory class. Now, as this is a blog, we’re keeping it simple and assuming that the classes we wish to use our factory to create have a default no-arg constructor and are public - you can add extra detail in to deal with constructor args.

Using Generic Methods

This blog adds to my previous couple of blogs about using generics, by introducing Generic Methods. My other blogs dealt with sample code that parametrise entire classes, but it makes more sense to parametrise a single method rather than a whole class if possible.

Using Generic bounded wild-cards in an API

Yesterday’s blog touched on the strange aspect of bounded wild-card generics showing that you can create typed collections into which you can’t add anything except null. The example, covering Fruit classes, begs the question of why you can write ? extends Fruit.

Are Generics Overly Complicated?

Generics, introduced in Java 5, are widely used in Java programs today especially in the arena of collection classes. What are not so widely used and little understood by average programmers are generics that use bounded wildcards (and don’t forget that by definition nearly everyone is average).

Using the Visitor Pattern

The visitor pattern is a method of separating an algorithm from it’s data with the result that you can add new algorithms easily without violating the open/closed principal.

Null Collections and the Special Case Pattern

In my last blog I covered the Special Case Pattern demonstrating a special case NullEmployee object in an employee details scenario. What it doesn’t cover is the

public List<Employee> getEmployeesBySurname(String surname)

method. This method must also adhere to the Special Case pattern and not return null when there’s no data available.