Posts Tagged ‘java’


I don’t believe in Groovy

In Java on 31/10/2010 by weirdfellow Tagged: ,

I always try to stay on the open minded part of the population. I have been trying with Groovy too… Half year later I can state – it is a fancy toy that looks great in the sample, but not a generic purpose language.

Groovy advocates usually have following reasoning:

Static typing doesn’t give any benefits – you have to unit test anyway
I am almost certain that nobody will ever hear from me that testing is unnecessary – quite the opposite.
But type checking allows to instantly identify a whole bunch of common coding mistakes, without need to wait for the tests to execute (and those can take some time)…

Java is too verbose, Groovy is much more compact.
Let’s make the identifiers optional wherever there is only one token in scope that fits! Compiler can figure things out and the code will be 17 bytes shorter!!! All this time I would have spent so much time on pressing the space…

Java is verbose – but what is wrong in being verbose? The more compact code, the more comments are required and it the end it sums up to the same number of bytes. I could start writing a more verbose, self explanatory Groovy code too. In other words – to make a code that is easier to read I would have to discard the compactness of Groovy. In such case – why bother with Groovy at all?

I don’t deny Groovy the right to exist – I definitely can see its the benefits. There are even things in Groovy I really like. Closures. Compact syntax for creating instances of ArrayList and HashMap. XML parsing. Groovy definitely can be useful.

However I am certain that those are only the situations when once you got working code, you never touch it again… Projects when the functionality has to be there now, and will be thrown away week later. Or tiny, very specialized classes you can throw away when they need to change and write them again. Refactoring a Groovy code will be a nightmare – because of its dynamic nature.

So – if doing anything with longer time frame, anything that might get refactored – keep away from Groovy.


2 matchers expected, 1 recorded.

In Uncategorized on 15/07/2010 by weirdfellow Tagged: , , , ,

EasyMock is really a nice framework for mocking interfaces, so you can reliably test your classes.

As always – everything is fine, unless you need to do something more complex. As long as you know all parameters passed to the mocks, there are no problems. But sometimes it is not possible to predict all arguments the mock will receive. A bit of research and here it is:

  MyData myData = EasyMock.createNiceMock( MyData.class );
  MyService serviceMock = EasyMock.createMock( MyService.class );

  expect( serviceMock.doSth( EasyMock.<File>anyObject(), myData ).andReturn( true );

Seems OK – doesn’t it? The code tells serviceMock to expects a call to doSth method. The second argument should be myData object, while we don’t care about the first one.

Unfortunately, you will get something like that:

java.lang.IllegalStateException: 2 matchers expected, 1 recorded.
	at org.easymock.internal.ExpectedInvocation.createMissingMatchers(
	at org.easymock.internal.ExpectedInvocation.(
	at org.easymock.internal.ExpectedInvocation.(
	at org.easymock.internal.RecordState.invoke(
	at org.easymock.internal.MockInvocationHandler.invoke(
	at org.easymock.internal.ObjectMethodsFilter.invoke(
	at org.easymock.classextension.internal.ClassProxyFactory$MockMethodInterceptor.intercept(

Unfortunately, it is not possible to mix values and matchers – a anyObject method is a matcher. To make the test execute correctly, all parameters should use matchers instead of just values. Solution is pretty straight forward – use eq matcher:

  expect( serviceMock.doSth( EasyMock.<File>anyObject(), EasyMock.eq( myData ) ).andReturn( true );

In addition to eq matcher, EasyMock does publish a handful of other matchers. Worth noting are aryEq for comparing the array contents and isA for checking the class of given object. The EasyMock site gives a full list of those.