Tag Archives: java

Migrating from Spring 3.2.x to Spring 4 and using ‘spring-mock 2.0.8’ gives “java.lang.NoSuchMethodError: org.springframework.core.CollectionFactory.createLinkedMapIfPossible”

So this is a very short post, with a ‘gotcha’. I wasn’t able to find anything about this, thats why I write it down here right now:

If you are migrating from Spring 3 to 4 and you have in your pom.xml the following dependency:

    <properties>
        <spring.version>3.2.4.RELEASE</spring.version>
        <junit.version>4.9</junit.version>
    </properties>
...
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-mock</artifactId>
            <version>2.0.8</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>${spring.version}</version>
            <scope>test</scope>
        </dependency>

Once you migrate to Spring 4 (lets say 4.0.3.RELEASE) and run your tests you might run into a following stacktrace:

java.lang.NoSuchMethodError: org.springframework.core.CollectionFactory.createLinkedMapIfPossible(I)Ljava/util/Map;
	at org.springframework.mock.web.MockHttpServletRequest.<init>(MockHttpServletRequest.java:107)
	at org.springframework.mock.web.MockHttpServletRequest.<init>(MockHttpServletRequest.java:210)
	at org.springframework.test.context.web.ServletTestExecutionListener.setUpRequestContextIfNecessary(ServletTestExecutionListener.java:171)
	at org.springframework.test.context.web.ServletTestExecutionListener.prepareTestInstance(ServletTestExecutionListener.java:100)
	at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:319)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:212)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:232)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:89)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:175)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

Then all you need to do is make sure that you *DO NOT* have ‘spring-mock’ still in your dependencies configured. As it seems that ‘spring-test’ has assimilated this in its own JAR in Spring 4.

Remove from POM.xml, re-run tests and be happy again. It took me a while to figure this out. I hope it saved you some time!

Coupling: The factory method

One of the challenges we face with coding is dealing with coupling. Coupling is an important aspect of programming, it tells us how much our code is tangled. When coupling is too high, we can’t easily re-use code. When the coupling is too low it does little. You can measure coupling, there are several metrics for it even (for instance “Coupling between Objects, CBO”).

In this blog post I’d like to talk about a subtle introduction of coupling: when you introduce a factory method.

Consider you have an interesting piece of code, and this piece of code has quite a lot of properties:

[sourcecode language=”java”]
class Person {
private String firstName;
private String lastName;
// .. more properties here

public void subcribeTo(Subscription subscription) {
// do something interesting here
}

}
[/sourcecode]

The problem is, because of the amount of properties and other dependencies, we’d like to simplify its creation by introducing a Factory method. In this case we are building a web application, so we take the Request as input to read the parameters:

[sourcecode language=”java”]
class Person {
private String firstName;
private String lastName;
// .. more properties here

public static Person create(HttpServletRequest request, .. more arguments here .. ) {
this.firstName = request.getParameter("firstName");
// .. read more properties
// .. set up dependencies, etc.
}

public void subcribeTo(Subscription subscription) {
// do something interesting here
}

}
[/sourcecode]

In the code that uses Person, it becomes easier to construct the Person and we’re happy with that. However, we have introduced coupling on several levels:

  • We construct the object with specific parameters in the create method. If we want to create from different parameters, we cannot use it. There is a coupling between the parameters and the properties.
  • The object is constructed using a Request object. We cannot now move the class to an application that does not use the web. A person has nothing to do with a request, it is just convenience that we put the factory method in the Person class. There is a coupling between the code of Person and the dependency delivering the Request object.

There are several ways to deal with this. But lets start with the last reason of coupling. It is easy to fix this coupling by creating a Factory class within your web application. From there you can generate the Person object out of a request. The Person class has no create method anymore, and thus is not tightly coupled to a Request class. The newly created Factory however is coupled to the Request, which is fine as it is meant to convert Requests into Person objects. Hence we could even name it that way:

[sourcecode language=”Java”]
class Person {
private String firstName;
private String lastName;
// .. more properties here

Person(String firstName, String lastName, …) {
this.firstName = firstName;
this.lastName = lastName;
// …
}

public void subcribeTo(Subscription subscription) {
// do something interesting here
}

}

class PersonFromRequestFactory {

// .. dependencies here

public Person create(HttpServletRequest request) {
Person person = new Person(request.getParameter("firstName"), )
// .. read more properties
// .. set up dependencies in Person, etc.
}

}
[/sourcecode]

Once we have this Factory, you can take it a step further:
If you have different kind of request parameters to create the same object you could create different methods in the new Factory:

[sourcecode language=”Java”]
class PersonFromRequestFactory {

// .. dependencies here

public Person createFromRegistrationForm(HttpServletRequest request) {
Person person = new Person(request.getParameter("firstName"), )
// .. read more properties
// .. set up dependencies in Person, etc.
}

public Person createFromSubscriptionForm(HttpServletRequest request) {
Person person = new Person(request.getParameter("givenName"), )
// .. read more properties
// .. set up dependencies in Person, etc.
}

}
[/sourcecode]

You could also create a Parameter object and go from there. For instance, if your web application uses Spring, you could wire your request parameters to an object (called “Form binding“) automagically and use that object as input in your Factory. This way it is type safe:

[sourcecode language=”Java”]
class PersonFromRequestFactory {

// .. dependencies here

public Person create(RegistrationForm form) {
Person person = new Person(form.getFirstName(), …)
// .. read more properties
// .. set up dependencies in Person, etc.
}

public Person createFromSubscriptionForm(SubscriptionForm form) {
Person person = new Person(form.getGivenName(), )
// .. read more properties
// .. set up dependencies in Person, etc.
}

}
[/sourcecode]

But how do you test all this?
Did you notice the Person has private fields, and no get/set methods? The only way to set the fields is using the Person constructor. How do you test the correct construction of this Person class from the request? Since we are not able to read the properties, we have to use other ways to test that code. I’ll cover that in the next blog post.

A Randori with Corey Haines

Saturday 8th of September 2012.

I came to Amsterdam Amstel train station, to pick up Corey Haines who I had asked if he wanted to meet the local community in Amsterdam and have some fun coding.

After I first introduced myself to a complete stranger (I swear he really looked like Corey Haines :))…
I then walked to (the real and smiling) Corey Haines and got us to the car to get to our location.

It was a fun evening coding. Around 10 people came and we mainly focussed on coding. I want to share one of the highlighting moments (to me) of that evening.

A Randori.

I never did a Randori before, but I really liked this form of group programming, so let me share this with you. Perhaps you might want to try it yourself with a group of developers you know.

So what is a Randori?
If I had to put it in one sentence: A Randori is a pair-group-rotating-programming session.

What we did
We did a Kata, but not all by ourselves… we did it all together.

Doing a Kata on your own is fun.
Doing a Kata with multiple people surely would be more fun right?

In this case we did the LED Display Kata.

But how did we do it as a group? Basically it works like this:
You have one person controlling the computer (called the Driver). Another person, called the Navigator, has a say in what should be made (design-wise). The Driver and the Navigator form a pair.

The rest of the people (the Audience) has a role as well:
When doing the Kata (in TDD of course), while you are in the red phase (test fails), the Audience must remain silent while the Driver and Navigator try to get the test to green (test passes). The Driver and Navigator may talk and work it out. Once the test is green, the refactor phase starts, the Audience is allowed to bring in suggestions. Want to shut up the audience? Write a failing test 😉

After a few minutes (in our case 5 minutes) you switch roles:
Navigator becomes Driver
Driver becomes Audience member
someone from the Audience becomes Driver

That’s a whole ‘session’. Reset the timer, and continue with the Kata where the previous pair left off.

Since you cannot write new code without a failing test, the Navigator is obliged to write (or let the Driver write to be more exact) a failing test first.

To avoid major rewrites of the code, there is a restriction to the Navigator. He may only refactor big changes after introducing an amount of new tests. Only when the tests pass, the Navigator may introduce major design changes.

So why is this fun?

It is fun for several reasons:
– It resembles a real world problem, where you have to work with existing code (and you can’t change the whole design because you feel like it).
– It’s fun to have short discussions about the code and its design
– You learn a lot from others when discussing code and design
– You learn how Java sucks by having no String.join() 😉

Picture or it did not happen!
Here you can see Corey Haines (at the left) in the session, looking at code that Arjen (at the right) is typing. And yes, I am taking this picture so you don’t see me on it of course! 🙂

Recap
Doing a Kata is a fun excersise alone. If you are with a group of people you could consider doing a Randori, and have fun coding together. The Kata itself is only the means to pair program, fix a problem, in existing code you did not write and trying to

Practical: What do you need
– A group of people (around 10 people)
– A computer with a dev environment installed (testing framework required)
– A big screen / a beamer

Thanks!
Special thanks to Corey Haines for coming over and let us have this experience!

Footnote: Later Arjen, Daniel and I had worked on the LED Kata again in a teamviewer session. We made a working solution (we wanted to crack the problem badly), which is also on Github.

What is wrong with this code #02

Given that the functionality of the method toGenericObject must be preserved; there is something obviously wrong in this code, can you find it?

If so, can you think of an easy solution?

[sourcecode language=”java”]

public MyObject {

private String myField;

… (imagine multiple fields) …

public GenericObject toGenericObject() {
GenericObjectFactory genericObjectFactory = GenericObjectFactory.getInstance();
GenericObject genericObject = genericObjectFactory.create("myObject");
genericObject.setField("myField", myField);
// imagine multiple lines using genericObject.setField("field", field)
return genericObject;
}

}
[/sourcecode]

My answer for – What’s ‘wrong’ with this code ? #01

I asked what was ‘wrong’ in the following code. I had put ‘wrong’ in quotes, because it is an ambigious term. Here is the code:

[sourcecode language=”java”]
if (null == sessionProxy.getShoppingCart()) {
throw new IllegalStateException("ShoppingCart may not be null");
}
[/sourcecode]

One thing that we find here, is the use of a session proxy object. This is convenient, because it can do things for us at a centralized place.

So what is wrong?
In my opinion there are several things wrong with this code:
– violation of the Single Responsibility Principle
– dealing with null

How to fix this?
Fixing this may not be as obvious as how to detect flaws. This is existing code we are talking about, and you can’t just make changes without making sure you don’t introduce regression.

Solving the violation of the Single Responsibility Principle
We are reading the state of the sessionProxy to execute business logic. We are actually only concerned if the shoppingCart is set on the session. This could be via a null reference, but it could also be done in a different way. What we want is this:

[sourcecode language=”java”]
if (!sessionProxy.isShoppingCartSet()) {
throw new IllegalStateException("ShoppingCart may not be null");
}
[/sourcecode]

The method isShoppingCartSet() returns true or false. The implementation will look like this:
[sourcecode language=”java”]
public boolean isShoppingCartSet() {
return getShoppingCart() != null;
}
[/sourcecode]

The subtle difference is that we now have delegated the question “is the shopping cart set on session” to the class that is responsible for knowing, the sessionProxy.

Solving: Dealing with null
Another advantage by using the isShoppingCartSet method is that we minimize the amount we have to deal with null. We don’t need to check for null explicitly everywhere, we have centralized in one class.

Dealing with null can cause problems, the sooner you don’t have to worry about things being null, the better.

Instead of using a isShoppingCartSet method we could throw a checked exception in the getShoppingCart method. I like checked exceptions, because it forces you to deal with these exceptional situations. It also solves the null problem, as you know it always returns a value or throws an exception when it is (but should not be) null.

There is on caveat here: what if there is existing code relying on the value being null?

The real question is: What does the null value mean? Often it is abused as a status. Some people even use null as a “third boolean” (ie Boolean is ‘true’, ‘false’, or null for ‘unknown’).

As I see it you have an ideal path you want to execute, and then there are things that can go wrong and must be dealt with. In this case, we would expect a shoppingCart so we can do stuff with it. But, if it is not there, we catch the exception and execute other business logic we would otherwise have done with a ‘is null’ check. Ie:

[sourcecode language=”java”]
ShoppingCart cart = sessionProxy.getShoppingCart();
if (cart == null) {
// do some business logic where cart is null
} else {
// other logic
cart.getSomeProperty();
}
[/sourcecode]

turns into:

[sourcecode language=”java”]
try {
ShoppingCart cart = sessionProxy.getShoppingCart();
cart.getSomeProperty();
} catch (NoShoppingCartSetException e) {
// do some business logic where cart is null
}
[/sourcecode]

The second example clearly defines a ‘happy path’ (within the try). If you use checked exceptions consistently, you will notice your code will become easier to understand. Try it!

What if I don’t want to add an exception to the getShoppingCart method in my current proxy class?
In these cases I would suggest to create a child class of the sessionProxy, which does throw an exception. In the cases where you are absolutely sure that the shoppingCart may never be null, you can use this stricter version of the sessionProxy and deal with exceptions.

Another way of dealing with null – upon construction?
It is also possible to check for null in the constructor(s) of the sessionProxy class. In the case of a http session proxy, it would mean you have to make it immutable to make this work. The reason is that the http session is mutable, even once you have created a sessionProxy. Checking for null values at construction will not guarentee the values are not set on null later on. To fix this, you should create a ‘snapshot’ of the http session at time of construction of the sessionProxy. You read out properties, check for null and set values in private final fields. When you access the fields, you retrieve the fields themselves, and not access them via the http session.

Ie, this:
[sourcecode language=”java”]
private final HttpSession httpSession;

public SessionProxy(HttpSession) {
this.httpSession = httpSession;
}

public String getProperty() {
String value = (String)httpSession.getAttribute("PROPERTY_KEY");
if (value == null) throw new PropertyNotOnSessionException("property was not set on session.");
return value;
}
[/sourcecode]

turns into:
[sourcecode language=”java”]

private final String property;

public SessionProxy(HttpSession) {
this.property = (String)httpSession.getAttribute("PROPERTY_KEY");
if (this.property == null) throw new PropertyNotOnSessionException("property was not set on session.");
}

public String getProperty() {
return property;
}
[/sourcecode]

Concluding
A few lines of code, and yet so much to improve. We have found that:

– We can push the null check into a method of the responsible class. Making the class itself able to answer this business logic.
– We should throw an exception when we want to return null. Dealing with null is hard. When you don’t have to deal with null, your code will get much easier.
– When throwing an exception has too much impact, create a child class which can throw exceptions to reduce impact on current code.
– Checking for null upon construction, for a session proxy, is not possible. Only if you create a DTO out of it (but not a proxy).