Mike`s Blog

Let's pretend Oracle makes some good database stuff. What they apparently do really bad: Java drivers. The Oracle Thin JDBC Drivers are so bad, that there is a whole bunch of vendors implementing their own drivers. Commercial drivers.

(We are not talking about some opensource guys trying to circumvent a license agreement by implementing a free version, so they can put drivers into a free tool. No we're talking about high-quality and sometimes high-priced replacement products.)

I didn't believe what I was hearing from friends, but this week, i trapped into it on my own. Let's suppose you've got some code which inserts a large numeric value like 12 Million Euro into your companies database...

• Comments (0)
• Trackbacks (0)
• Continue reading "Oracle knows nothing about Java"

Is this a timing problem in Eclipse, in JUnit4 or in Java 6 (Mustang) ?

See the test, which is assumed to fail after approx 5seconds. In reality, you have to wait twice the time - 10 seconds - for it to fail. Why?

• Comments (0)
• Trackbacks (0)

I've done a lot of String Concatenations to convert ints to Strings, so I can create BigDecimals. After some time, i learnt that this is ugly. Code like this can be found everywhere (not only in my code)

private static String EMPTY_STRING = "";
int invoiceNumber = 123;
new BigDecimal(EMPTY_STRING + invoiceNumber);

Why don't we use the much simpler form?

BigDecimal.valueOf(invoiceNumber);

Isn't this much easier to read andunderstand? Why the heck do we do such horrible things in the first place? A customer asked me and my collegue why we often use the term ""+int to convert something into a String and I couldn't give him an answer. I was so shocked as it turned out to be true and that I didn't know why I did that stuff over and over again.

Bad habits last long.

• Comment (1)
• Trackbacks (0)

EasyMock Arguments

To mock objects, you need to know which methods are called with what parameters, so you can assert them.
For simple parameters like Strings or numbers, this is easy and you can record the value just by simply calling
the method:

IMyMock mock = myControl.createMock(IMyMock.class);
mock.doSomething("Foo"); // Point of interest
mock.replay();

// This will call IMyMock.doSomething("Bar")
// public void methodUnderTest() { myMock.doSomething("Bar"); }
classUnderTest.methodUnderTest();

// This will compare "Foo" with "Bar" and fail the test
mock.verify();

Here, mock.doSomething("Foo") will 1) record the method invocation of doSomething and 2) record the value "Foo"
for the first and only parameter.

For more complex parameter objects, or if you want to ease restrictions, you will probably want
to implement your own EasyMock IArgumentMatcher. In this case, the actual parameter within the unit test
source code does not matter and you can use null for them...

• Comments (0)
• Trackbacks (0)
• Continue reading "EasyMock Arguments"

MiniSnippet of the Day - equals

Codesmell:

public boolean isFoo(String parameter) {
	return parameter.equals("foo");
}

Problem: parameter can be null, thus throwing NullPointerException

Corrected:

public boolean isFoo(String parameter) {
	return "foo".equals(parameter);
}

Solution: works also if parameter is null, no extra null-check is required (which could have been forgotten)

Always use a Constant as the object to call equals on, when the second object is variable.

There should be a Checkstyle or PMD rule for that.

• Comments (0)
• Trackbacks (0)