Posts Tagged ‘ Java ’

Java Open Source Programming book biled

Well I knew eventually the book would be biled.

While I usually find negative feedback very helpful (thanks Werner!), I feel that Hani’s review has unfortunately missed the point of the book.

The book is based around the theme of improving development productivity and the quality of real world systems through simplifying code. Whereas many other books on the shelves at the moment are ‘bibles’ that provide a comprehensive in-depth guide to specific technologies, this book tries to do something different by illustrating how using some simple tools and design techniques you can stay on top of development. Admittedly, the title of the book doesn’t convey this – I hope that really isn’t a reason to read the book.

The simplicity expressed in the JUnit and mock objects chapters was exactly what we were trying to get across to the reader. Rather than providing a brute-force approach to testing complicated applications by using tools equally as complicated, we advocate simplifying the design of applications.

Through using techniques such as test driven development (though not exclusively), you are driven towards this simpler design. Rather than show how you can use mock objects to test complicated things like environment, resources and complicated dependencies, we show how you can alter the design of your code so these complexities are encapsulated behind simpler abstractions. The examples used in many of the chapters are not much simpler than those used in my real applications at work – and I don’t write pet stores for a living ;).

There are also books that go into the theory behind simpler design, we try and make it more concrete by showing how you can make these kind of abstractions with technologies that are common in the Java development community. We often promote the use of one technology over the other (for example WebWork over Struts or Hibernate over CMP) because these are more geared towards simplicity and abstraction. In these cases we often summarise the key differences between these technologies. That’s not to say that this book is useless to you if you are not using these technologies as the simplicity we illustrate is beneficial in many kinds of application development.

Even if you are familiar with (or choose not to use) the technologies explained in first half of this book, the second half really captures what we are trying to get across. It illustrates by example how the technologies and techniques come together in many small steps, creating a system that can evolve, scale and has a high quality of design.

One of the most challenging tasks of writing a book is putting yourself in the mind of the reader audience. Some content may be obvious to some people. Some people may find none of it useful. Our aim is for most people to find most of it useful, which as Hani has made clear, unfortunately means most people find some of it completely useless.

If Hani’s review has put you off from reading the book, please take time to look at some other reviews (positive and negative) and remember that Hani’s view more-often-than-not skips over the positive aspects of something he is critiquing.

XStream 0.2 released

See this.

Java Open Source Programming book reviewed on TheServerSide

Dion Almaer has reviewed our book:

* Full review
* Discuss the review

I’m glad he picked up on many of the points we tried to emphasise to make the book stand out from the crowd.

XStream is nearing a release

XStream is a simple object -> xml -> object serialization tool. There are many other tools that do similar things out there. Here are some of the features that distinguish it from the others:

* Very fast.
* Requires no custom mappings to be created.
* Can serialize objects that have private fields and non-default constructors.
* Handles arbitary objects and collections.
* Produces very clean XML; the kind a human would write.
* Does not duplicate any information in the XML that can be obtained via reflection.
* Decoupled from XML implementations. Use it with DOM, JDOM, DOM4J, or even non-XML streams (such as custom configuration objects, YAML or properties files).
* Open source, BSD license.

Here’s an example chunk of XML produced by XStream:

Joe
Walnes

123
1234-456


123
9999-999

New Book: Java Open Source Programming

Our new book, (With the snappy title, Java Open Source Programming : with XDoclet, JUnit, WebWork and Hibernate) hits the shelves this months. A joint effort between Pat Lightbody, Ara Abrahamian, Mike Cannon-Brookes and myself.

This book :

* Highlights many of the complexities of J2EE and shows how to leverage best of breed open-source tool to reduce or even eliminate these.
* Introduces you to some of the coolest open-source projects in the history of mankind.
* Demonstrates the test-driven-development to drive design (and even some tests).
* And most importantly of all… shows how to combine these tools and techniques to deliver an end-application.

Go pre-order!

Design by contract: testing implementations of interfaces

Here’s a nice way of associating contracts with interfaces and testing the implementations conform.

A sample interface:

interface CheeseMaker {
int getCheeseCount();
void addCheese(Cheese cheese);
}

With the contracts:

* there should be zero cheeses on creation.
* adding a cheese should increment the count.
* unless the cheese is a duplicate.
* when adding a cheese, the cheese cannot be null.

You can create an abstract unit test for this interface that tests these contracts. The only thing it doesn’t do is provide an implementation – instead it has an abstract factory method.

public abstract class CheeseMakerTest extends TestCase {

// abstract factory method
protected abstract CheeseMaker createCheeseMaker();

public void testZeroCheesesOnCreation() {
CheeseMaker cheeseMaker = createCheeseMaker();
assertEquals(0, cheeseMaker.getCheeseCount());
}

public void testAddingACheeseIncrementsCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Wensleydale"));
assertEquals(2, cheeseMaker.getCheeseCount());
}

public void testDuplicateCheesesDoNotIncrementCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Cheddar"));
assertEquals(1, cheeseMaker.getCheeseCount());
}

public void testNullCheeseCausesIllegalArgumentException() {
CheeseMaker cheeseMaker = createCheeseMaker();
try {
cheeseMaker.addCheese(null);
fail("expected exception");
} catch (IllegalArgumentException e) {} // good
}

}

Now, every time you create an implementation of CheeseMaker, the test should extend CheeseMakerTest and you inherit the contract tests for free.

For example:

public class BigCheeseMaker implements CheeseMaker {
// ... ommited for sanity
}

public class BigCheeseMakerTest extends CheeseMakerTest {

// factory method implementation
protected CheeseMaker createCheeseMaker() {
return new BigCheeseMaker();
}

// ... any additional tests go here

}

It’s important to note that this tests the contract but does not enforce them. It’s very flexible and there are very few contracts (if any at all) that couldn’t be expressed in a unit-test.

This helps defensive development with the added safety of unit-tests.

As a bonus, you can use TestDox to generate documentation for interfaces (much more useful than implementations), like so:

h4. CheeseMaker

* Zero cheeses on creation.
* Adding a cheese increments count.
* Duplicate cheeses do not increment count.
* Null cheese causes illegal argument exception.

Agiledox

Chris Stevenson, fellow team-member, has started Agiledox, a small project to collect ideas and tools for automating documentation.

It is typical in agile projects that the code and design changes so quickly that the documentation (if any) never keeps up. We are using Agiledox on our current project to help give us all a high-level map of what the system does at all times.

When practicing *collective code ownership* it is vital that all developers know how the entire system works, not just _their_ bit (they have no bit). With bigger systems that are constantly evolving it is unlikely that any one person knows how it all works, so it’s nice to have a higher level roadmap of the system to look around before drilling into some code. Of course, this is no substitute for good communication – but it helps.

The first deliverabe in Agiledox is Testdox . It autogenerates documentation from testcases. Wow! How?

Simple. All it does is look at a test class and all the test method names and convert them from camal case Java names to sentences. Genius!

You may laugh, as I did. But I was amazed at what it produced for our project.

There’s a catch though. It worked for us because we are well disciplined in the way we write tests. For a start, we were already in the habit of writing test case method names that describe what a class should _do_ rather than what all the methods are. Don’t moan that this low emission petrol isn’t great when you’re trying to put it in a deisel engine.

Run Testdox through WebStart.

Here’s a handful of docs generated for our project. Sweet huh?

h3. MenuModel

* View can be bound to a model
* Two views can be bound to one model
* Model contains menu text
* Model contains menu text after it is renamed
* View is populated from prepopulated model
* Model can be cleared
* Model can contain separator

h3. CsvTableModel

* Column definitions are read from first row
* Values can be read from rows
* Column definition values return underlying value
* Model can be reloaded
* Column can be marked as date

h3. NewOrderFinder

* Order with fills are returned
* Old orders and old fills are filtered out
* Old orders with new fills are not filtered out
* Assumed legs are filtered out
* Last check is maintained
* Spread components are grouped together

StaticMesh first cut

Rune Toalango Johannesen has created a first cut of StaticMesh – an offline version of SiteMesh for building static web-sites.

Like SiteMesh, it takes a plain HTML document (content) and an HTML decorator (presentation) to generate some pretty content as its output.

Unlike SiteMesh, it does not require a runtime Servlet engine to do this. It gets it content and decorators from files and outputs to more files.

You can run it as a standalone application, embed it in existing apps or use Ant to invoke it.

The Ant task usage is as simple as you’d expect:





Content pages are plain old HTML. Anything can generate these (even MS Word!).

Decorators are also plain HTML with lots of prettyness. SiteMesh parses the content pages, which are made available to the decorator using Velocity variables such as $title and $body. Velocity is very friendly and doesn’t confuse web-development tools such as DreamWeaver.

MockObjects Java 0.09

The latest release of the Mock Objects Java project is available. The dynamic mock generation API has been improved greatly and it now allows a lot more flexibility in setting up expectations and return values resulting in less brittle tests.

“Website”:http://www.mockobjects.com/
“Download”:http://sourceforge.net/projects/mockobjects/