Switching Bloggers

I've decided to switch to Wordpress.com. I hated to do so after just starting to get the ball rolling on my posts here, but Wordpress has some really nice features and I thought it was better to do it now than wait until later.

Most notably for me I like the tagging and the feedback you get, when someone comes to your site from the result of a search, you can see what they were searching on, when they came to your blog. Also, they seems to have a wider variety of layouts, and they're editor is a little nicer.

Sorry Blogspot :( .. and finally, when I put :( on my Wordpress entry, it automatically changed it to an emoticon. How cool is that!.. How nerdy am I :)

My new blog is at ericmaxwell.wordpress.com.

Groovy Ignores Scope

Let me start out with.. I like Groovy. I haven't used it extensively yet on any of my projects, but I have done odd jobs with it.

With that said, there seems to be an important issue with Groovy in my opinion and I don't understand why there aren't many posts about it, or why it's not mentioned in the documentation, or why it still exists... Groovy does not currently enforce scoping constraints.

Take the following for example:
class PrivateMethodClass {

private static String privateMessage = 'foo'
private static String getPrivateMessage() { 'boo' }

private String privateInstanceMessage = 'instanceFoo'
private String getPrivateInstanceMessage() { 'instanceBoo' }

private static void sayHelloStatic() { println('hello static') }
private void sayHelloInstance() { println('hello instance') }
}


If you were to attempt to call any of these private variables/methods in Java, outside of the PrivateMethodClass, you would get an error when attempting to compile. In groovy on the other hand, this is totally acceptable to do.

So in Groovy this:
class PrivateMethodClassTest {

public static void main(String[] args) {
println 'attempt to call static.'

PrivateMethodClass.sayHelloStatic()

new PrivateMethodClass().sayHelloInstance()

println PrivateMethodClass.privateMessage

println PrivateMethodClass.getPrivateMessage()

println new PrivateMethodClass().privateInstanceMessage

println new PrivateMethodClass().getPrivateInstanceMessage()
}
}

Yields:
C:\projects\grovvyScopingFlaw>groovy PrivateMethodClassTest.groovy
attempt to call static.
hello static
hello instance
foo
boo
instanceBoo
instanceBoo

There is a Jira issue for this at http://jira.codehaus.org/browse/GROOVY-1875 and it is supposed to be fixed in 2.0 if I'm reading the issue ticket correctly.

I debated about whether I should post about this or not as I thought this might be old news, but as I mentioned this to people around me who are very interested in Groovy, I got a lot of surprised responses. So there it is.

Annotation @Override: Making the compiler work for you

I was writing/running JUnit tests for a project at work today when I came accross some odd behavior with the assertEquals method. Before I go into the problem, let me over simplify the model I was working with.

I created a class Foo that extended a class Boo, written by another project team. Boo overrode the Object.equals method (or so I thought), as shown in the diagram below.

Now from the simple diagram, coupled with the fact that you know somethings up, you may have guessed that they didn't really override the equals method in Boo. They overloaded it by changing the signature from

boolean equals(Object boo)

to

boolean equals(Boo boo)

This was a mistake on their part, an oversight on mine, and the result was the following statement in my JUnit test failed

assertEquals( fooA, fooB );

Whereas the following statements passed without a problem.

assertTrue( fooA.equals( fooB ) );

assertTrue( fooB.equals( fooA ) );

It took me a while to take notice of the signature mismatch on Boo.equals. (no jokes or insults please :) ).

It passed on assertTrue because assertTrue invoked fooA.equals( fooB ), and when the JVM didn't find an exact signature match on the method in Foo, or a method of equal name but more general types, it went to the next closest match, which was the equals method of Boo taking a Boo for comparison.

It failed on assertEquals because assertEquals treated both objects passed in as java.lang.Objects. This meant that the equals method of Object, unless overridden, was going to be called. Since it wasn't overridden, the result was the equivelant of fooA == fooB.

My Point

My point is that, if they had put an annotation tag @Override on their equals method, Boo wouldn't have compiled in the first place and I wouldn't have gone through this. And I thought it was worth brining attention to on my blog as I haven't seen many people use it yet since made available in Java 1.5.

My First Post

So I have a blog. What does one say on their first post? I do not know.

Weebles wobble, but they don't fall down!

How's that. Future entries will hopefully be more technical in nature than this.

That's all for now. Thanks for reading.