New WP Theme – No Fuss

I got bored with using a default WordPress theme, so decided to make my own. Again, using BlankSlate as a base, I call it ‘No Fuss’. I’ll be maintaining it for my own use on GitHub, but feel free to fork it or to contribute if you like it.

There’s a little work to do in tidying up the CSS, but I like it as it is for now and will develop it further when necessary.

Enjoy!

Blank Slate

I’ve just finished turning the band website into a WordPress site. Well, when I say ‘finished’, I mean I’ve put it up live because it’s in a place where I’m comfortable that the theme is pretty close to the original look.

Over the last few months I’ve taken a liking to WordPress and have used it more and more for various projects. There may not always be a plugin to do exactly what I need, but it’s pretty easy to pull something together yourself.

I didn’t want to change how the band website actually looked – I just needed a way for us to be able to easily add photographs, gig dates, and videos. Since the site itself has always looked pretty simple, I spent a while looking for a stripped down theme that I could customise before settling for Blank Slate. You can’t really get much more stripped down than a full CSS reset and the bare minimum markup!

The total time taken to convert the website from pure hand-written HTML to a WordPress theme with content, (including figuring out the plugins I wanted and customisations to those) was about a single day, and most of that was eaten up by me trying to decide which events calendar plugin to use.

I still need to do some SEO stuff and re-do the social media links, but all in all I’m pretty happy with how the conversion went. The site looks pretty much exactly the same, but we now have a real back-end that will allow us to manage our photos, videos, and gig dates far more easily.

Boxing with Java

A bug was recently identified in a project I’m working on. Check the following code out:

Naughty naughty. I had done a very silly thing and used == to test equality of Integer objects! As we all know, when comparing equality on objects we should be using .equals(). However, this bug was intermittent. Comparing Integer to Integer like this works. Sometimes.

Let’s see what’s happening here:

First, we need to check what happens when we compare two ints:

Output:

Comparing unboxed 10 to 10
true

This makes sense. A is of an equal value to B.

Now let’s compare two Integer objects:

Output:

Comparing boxed 10 to 10
true

Great – we have equal values, right? Where’s the problem?

Here:

Change the values to some high number. Let’s say 1000:

Comparing boxed 1000 to 1000
false

Depending on your particular implementation of Java, the value required to trigger this behaviour may vary, but in my case, the equality result changes when a and b are set to 128.

UPDATE: As pointed out by Edwin Nathaniel in the comments, any Java implementation should cache Integer objects according to the following:

“Cache to support the object identity semantics of autoboxing for values between -128 and 127 (inclusive) as required by JLS.
The cache is initialized on first usage. The size of the cache may be controlled by the -XX:AutoBoxCacheMax= option.”

This means that the Integer cache limits are configuration dependent, not implementation dependent. Props to Edwin (who also has a rather delicious looking blog) for schooling me on this subject!

Let’s change the code a little and turn our primitives into objects when we do the comparison (this is what’s already happening, by the way, it’s just a little less obvious the way I’ve illustrated it here):

Output:

Comparing boxed 1000 to 1000
false

In case you missed it, the checkBoxed method is expecting Integer objects, not primitives. We pass it primitives, and autoboxing is applied by the compiler, cramming our primitives into objects and giving us a nasty surprise.

Autoboxing allows developers to forget about the tedium of converting between primitives and objects, resulting in tidier code and, in this particular case, more headaches. You don’t gain anything performance-wise as the compiler will still generate the ‘boxing’ code, but it does tend to make life more convenient.

If you want to avoid this problem, you can do the following:

Comparing these two using the checkBoxed method will always output ‘false’, because you are explicitly creating two different objects. The fact that they represent the same value is irrelevant to the JVM. It sees two different objects and tells you so.

You can also use the following comparison instead:

Perhaps the best way to avoid this problem is to be consistent and enforce the rule across your team. Keep in mind that you don’t always know how Bill has implemented his bit of code, and he doesn’t know how you’ve implemented yours – so decide how you’re going to deal with this potential pitfall and make sure you both keep it in mind. Unfortunately for me, I’m the only person working on this project so I can’t blame somebody else.

It’s worth pointing out that autoboxing is applied to all primitive wrapper types, not just Integers, so it is an important feature to keep in mind.

If you use Eclipse, turn on the following handy feature to help you find where autoboxing / unboxing could occur:

This will highlight your code with the following warning:

This is one of those features added to make your life easier. Unfortunately, people new to Java, or idiots like me, may not understand what is happening here and could be writing code laden with boxing issues. Only a good set of coding standards, and a decent code-review process, will help you catch these issues before they become a real problem out in the field.