Friday, 29 May 2009

Code Coverage of Junit in Ant without instrumentation

Until today we were using Corbertura to do our code coverage report. This required a two phase build process in which the first phase involved compilation, instrumentation and testing, the second phase being compilation and packaging.

Arum DataEye was taking 11 minutes 31 seconds to build and this felt a little too long, even though we're building and testing 26 OSGi bundles and two pure ActionScript libraries. This also violate's Fowler's keep the build fast rule.

I've been using the Eclemma plugin in Eclipse to give me coverage reports on the fly. The integration is simple but effective, always the best way. It occurred to me this morning that this plugin must be using something to do the coverage and that's when I discovered Emma.

So I decided to set about coverting our Ant based build to use Emma instead of Corbertura. I hit a snag - you still need to do instrumentation to run it with the JUnit task ... or at least it appears you do.

Emma provides a number of Ant tasks, most relevant to this discussion is the emmajava task which essentially just replaces the java task setting up Emma support automatically. However, this wasn't going to be enough to get on-the-fly instrumentation running with JUnit.

To cut a long story short, you simply have to trick the Junit ant task in to running the Emma command line runner. This is done with the following Ant snippet:

The important thing here is that the Junit task is forked. We then fool Junit in to running the Emma runner for each fork and voila, no need to instrument.

As a result, we were able to reduce our build process to a single phase of compilation, test, and packaging reducing the total build time Arum DataEye to 4 minutes 33 seconds! A massive saving of nearly 7 minutes!

This (fairly old now) post will get you a good chunk of the way and of course there's the Emma user guide.

Thursday, 28 May 2009

OSGi ClassCastException with Equinox 3.4

Edit - problem solved thanks to Stuart McCulloch. I need to refresh the framework as well. So stopping both bundles, updating them and then calling refresh before starting them fixed the problem.


OK, I'm hoping this isn't going to make me sound like too much of a noob but I've been experiencing ClassCastExceptions with some bundles I've been playing around with.

This is using Equinox 3.4 on Mac.

Essentially this is the situation:

Bundle A exports an interface and is designed to load and create instances of classes from other bundles that have a certain manifest header and implement this interface.

Bundle B has a class which implements the interface and the classname specified in the required manifest header.

Bundle A creates an instance of Bundle B's class - using Bundle B's loadClass method to get the class. No problems thus far.

However, OSGi is a dynamic environment so maybe Bundle A needs to go away or be updated for some reason:

Update Bundle A and a ClassCastException is now thrown when loading Bundle B's class. That seems reasonable because I haven't updated Bundle B though I am surprised it is still in the STARTED state. Since it had a dependency on the now updated Bundle A I kind of expected it to be in the RESOLVED state.

So I take more severe action:

Stop Bundle A (now in STOPPED state).

Stop Bundle B (now in STOPPED state).

Update Bundle A (now in INSTALLED state).

Update Bundle B (now in INSTALLED state).

Start Bundle A (Bundle B now in RESOLVED state).

Start Bundle B and I still get a ClassCastException while trying to create an instance of Bundle B's classes even though both bundles have been updated.

Same thing happens even if I completely uninstall Bundle A and/or B.

What I'm asking is should I get the ClassCastException after both bundles have been updated?

It is as though Bundle B is still using the class definition of the interface in Bundle A that was loaded right at the beginning of this exercise.

After an update of both bundles (and certainly a reinstall) I would have expected Bundle B to be using the interface definition from the recently updated Bundle A.

Any thoughts?

Thanks in advance.

The obvious answer is to create a third bundle that contains the interface in question, but then I have two bundles for my functionality and I only want one, especially since this is such a lightweight activity. Also, if I then update the bundle containing the interfaces I suspect that will mess things up for even more bundles.

Also, I really should try this on a different OSGi container such as Felix or Knoplerfish.

Wednesday, 13 May 2009

thoughts on jsr294 - v0.0.3

It's been a while since I posted some thoughts on JSR 294. I was quite vocal on the observer list some time ago but then decided that I should shut up since I am not on the expert group.

In all honesty, I find the JSR 294 mails confusing. The mails that appear on the EG mailing list (copied to the observer mailing list) seem to go round in circles and contain contradictory information, yet the spec lead seems determined push forward and still references vague and informal specifications that were published seemingly years ago, while seemingly ignoring the please of other members of the EG.

Frankly, reading the JSR mails makes me feel a little ill about the future of Java. JSR 294 is going to be a vague specification that breaks Java just enough to affect the leading module system (OSGi) in a very negative way. It wouldn't be so bad if I could see that Java would be in whole unaffected - because existing module system(s?) could just carry on unaffected and ignore the spec, but that just isn't clear.

My main worry is that 'modules' in Java will be come overly complex to achieve regardless of the module system by adding what appears to be minimal (and low-value) changes to the language.

Thursday, 7 May 2009

MoneyTracker 1.3

Made a minor update to MoneyTracker which can be downloaded from the previous URL and now from the Android market, though I'm not sure how to find a public link for it yet.

Basically added a custom icon and correctly specified the minimum SDK requirements.

Next up, I'm going to look at graphics, animation and general Android games stuff... right now I'm wondering if you can talk to another handset via Bluetooth or worst case on a (WIFI) LAN, though I'm always willing to consider enhancements to MoneyTracker. :)

Wednesday, 6 May 2009

Android App : MoneyTracker

Here's my first (public) Android app:

And here's the source:

Basically you can specify a 'disposable' amount and then add expense items showing you how much is remaining. That's it, pretty noddy. It isn't a million miles from the notepad tutorial, the most significant difference being that I use db4o as the data storage instead of SQLLite. Unfortunately, that increases the apk file from 20k to 413k, but I am going to investigate getting that down to something more reasonable.

That said, being able to use db4o is much nicer than having to mess about with database tables and SQL. I had to write my own

I haven't actually tried this on an Android device yet, as I don't own one, so if someone wants to give it and try and let me know how it goes, I'd be grateful.

Obvious disclaimers apply - if your phone goes kaput, don't blame me. :)

This is also my first foray in to using Git and, which so far has been relatively easy to get on with. I guess I should have tagged/forked/branched(?) my changes from SQLLite to db4o, but I don't really know how just at the moment.

One of the things you get out of the box when using SQLLite is the ability to use the SimpleCursorAdapter which automatically maps some given data to the views in a layout. I of course had to do this manually, but given the number of lines of code I'd deleted because of using db4o adding these few lines of code was not a problem.

Android vs iPhone : The winner is ... Android

A friend of mine finally convinced me to have a play with the Android SDK. Since the 1.5 SDK is now available and 1.5 updates are slowly winging their way to Android handsets I decided to get stuck in and have a play.

I've had a MacBook Pro for a while, specifically for the purpose of building Mac OS and iPhone apps, but the one thing I've had to contend with is the Apple SDK. I can handle Objective C, trust me, but the examples are out of date and there's no simple tutorials which give you a broad overview of the device's capabilities. I love my Mac and the apps that I'm seeing become available for it are awesome and obviously developed with the Apple SDK. The iPhone has access to the very same SDK and even shares the same SDK documentation with notes and annotations when something is not available for iPhone.

All the Apple SDKs are low level. Programming in C was my first job, but rapid application development shouldn't require knowledge of pointers and there's no way to avoid this even with Objective C. The one thing that is slightly better is the UI builder. The Android UI builder is not quite so slick, but eventually I think a UI for building a UI can become a hinderence and I certainly end up defining the UI programmatically and not using the WYSIWYG features of the toolset. This is unavoidable with the Apple SDK because it is creating binary resources for you as you build your UI.

As a Mac user it is also easy for me to forget that you have to use Mac OS to develop with the Apple SDK. For Android the SDK will run on any platform supported by Eclipse and the SDK, which I believe includes Mac, Linux and Windows. A much wider community of developers can instantly get stuck in.

The first thing that hit me about the Android SDK was how easy it was to get going. The download page has detailed instructions on how to get setup, including downloading Eclipse, installing the plugins and installing the Android SDK. There are then two tutorials - a very quick Hello World and a more indepth Notepad example. Neither are particularly broad, but introduce you to the essential concepts.

Note that you don't even need to use Eclipse - but it is a great tool and the Android peeps have provided some great tooling based on it. Likewise I can imagine how you might not actually need to use XCode to develop Mac / iPhone apps, but I would think XCode makes it a lot easier.

(Once you've done these tutorials I recommend reading this: it blew my mind - in a good way!)

So I was able to do in a couple of evenings with Android what I had failed to do in several months of having the Apple SDK at my finger tips... but of course, that's just me. I believe there are several other reasons why Android 'wins'.

As a techy and developer, the most important feature that Androd has, which iPhone doesn't, is the ability to run multiple applications at the same time. This is actually very clever life-cycle management (see above link), but the iPhone only allows one foreground application and iTunes to run which is very limiting and in flexible. The Android SDK encourages collaboration, which seems to be the Google way.

After a bit more investigation I find that the way Android handles applications is just mind blowing. If my Android application (as complicated as I want, e.g. with multiple views, called Activities) exposes a service, other applications can access that service. No big deal until you find out that Android is able to instanciate *just* the service part of my application if it is not already running.

There's a whole bunch of other amazing technical things happening under the covers, and it is all layed out to bare on the page. In contrast with iPhone, while all the technical information for iPhone is available online, I find it difficult to read, obtuse, out of date and with unclear examples.

The next reason Android 'wins' is that it isn't restricted to a single device. OK, iPhone apps work on iPod Touch as long as they don't use GPS, Mic or Camera, but Android is already appearing on multiple handsets (the G1, the Samsung i7500 and HTC Magic) and on multiple providers (t-Mobile and Vodafone). There is no way the likes of Orange will let something like Android elude them, so it won't be long before all the carriers jump on board and before we know it Android is everywhere. Where will iPhone be ... well, still on the iPhone and in O2 of course, though I can't imagine O2 not having an Android phone as well, unless they've agreed not to with Apple.

Anything else? Well one more thing - the market place. Apple's App Store is rapidly gaining a reputation as difficult for developers to interact with. Android's approach is typically Google like in that it is more open. You don't have to use the store to get your apps on to devices, and Google isn't as restrictive about what apps it allows. Further more the Android market place has a refund policy. Return the app within 24 hours for a full refund.

Does iPhone have anything going for it? Well yes, a few things, but I think they are actually pretty minor. Firstly, it is ultra-cool looking, like all Apple gear. Secondly, it has multi-touch. As far as I know multi-touch isn't supported on Android.

Lastly, games. As weird as this is, given how hard it is to get games for Mac, games for iPhone are appearing all the time and by big name developers, e.g. Spore and I recently purchased the arcade classic Silent Scope. With people like John Carmack of "id Software" saying things about iPhone like:
more powerful than a Nintendo DS and PSP combined
it is easy to see that people's attention will be directed at the iPhone/iPod Touch as a mobile games platform. I'm not going to disagree because I love playing games on my iPod Touch. "id Software" recently released Castle Wolfenstein 3D for the iPhone - pretty cool.

I would definitely be interested to see a comparison of the graphical capabilities of iPhone vs Android. Of course, the advantage that Android has is that someone could create a piece of hardware that runs Android with gaming specifically in mind - the iPhone still has to wear its one size fits all glove.

So in conclusion, while I think iPhone is the 'coolest' handset on the market at the moment, and seems to be a really good gaming platform gaining popularity with games developers, from a phone application point of view iPhone doesn't do anything Android can't do (apart from multi-touch) and in fact, Android does so much more. In addition, by being handset independent (there are rumours of an Android driven 'web pad' on the horizon), it makes more sense for developers to target Android than it does iPhone, especially since it is easier and less restrictive for developers to get their Android applications out there.

I love my MacBook Pro for computing, my iPod Touch for music and cool games on the go and am waiting to get my hands on an Android phone for everything handset related.

Tuesday, 5 May 2009

Ebay Flash Error

This isn't the kind of thing you like to see just after you've made a payment on Ebay.
SecurityError: Error #2121: Security sandbox violation: LoaderInfo.content: cannot access This may be worked around by calling Security.allowDomain.
at flash.display::LoaderInfo/get content()
I'm sure it is innocent enough though. Having the debug version of Flash Player installed is a pretty scary business.

Sunday, 3 May 2009

Scottish Developer Day - Developer Developer Developer!

Yesterday was the Developer Developer Developer event in Glasgow. A Microsoft sponsored event arranged by the Scottish Developers group.

There were four tracks of talks, A, B, C and SQL Bits.

jQuery Deep Dive In
Andy Gibson

I've been waiting ages to get to a jQuery talk and find out what it's about so this was the first talk I went to. The speaker and most of the audience seem pretty in awe of this library, but I wasn't all that impressed. I'm sure it is an impressive piece of work under the hood, but the first thing that turns me off is the list of supported browsers, or rather the fact that there is a list of supported browsers. Just another reason why I think HTML/CSS/JavaScript are a dying breeds. No one supports standards in the same way. The most interesting thing I suppose is the fact you can use CSS 3 like selectors to find the exact element you want in a DOM tree and then manipulated. I guess this is handy if you're doing this HTML/CSS/JavaScript stuff all the time but it doesn't really have much impact on me.

The next thing I didn't like was all this passing of functions are around. People seem to love it, but it just makes the code hard to read and less metainable. However, in the constraint of an individual web page I suppose it doesn't matter so much.

TDD? I don't have time
Craig Nicol

Didn't really elicit anything new about Test Driven Development, except that the tools for working with Microsoft are not free like the they are for other platforms. However, I did like the big flashy arrow saying things like "Do something here" and pointing at the code, though I think that novelty would wear off quite quickly.

SQL Server Optimisation: Best Practice for Writing Efficient Code and Finding and Fixing Bad SQL to Improve Performance
Iain Kick

This was a great session. We use SQLServer with one of our DataEye customers, so this was of interest.

Iain started by going through the native tools available for looking at performance on SQL Server then ended by showing Quest's own product, which was frankly very impressive and I'll be talking to our DataEye customer to find out if they've used it.

What is functional programming?
Barry Carr

I was a little worried about this, especially since I'd more or less had enough Microsoft spin on everything all day, but Barry actually used Scala to talk about functional programming, so this was pretty good as Scala runs on both Java and .NET. Have to admit that I learned more from Barry's talk than I did from Ted Neward at The Serverside Java Symposium.

However, I'm still not sure where I see Scala or in fact any functional programming language, fitting in to enterprise. That said, the paradigm suits a parallel computing project quite well since immutability means that small chunks of work can easily be delegated to other processors, either on the same hardware node, or a remote one.

Apparently some people say that Scala will replace Java on the VM. I very much doubt that. It is a different way of thinking and the syntax is not straight forward. If anything I think that Groovy will have a bigger impact in the Java community as it isn't asking developers to deviate from anything they already know and can slot in to existing projects quite easily.

Scrum Pain: Lessons learned swimming against the current
Abid Quereshi

Finally, this was also a great session and I will definately be taking some feedback to my employeer. Courage!


Overall a great day, especially for the price (free). I even got a couple of free Microsoft t-shirts (great for painting, so I'll be letting my wife have them) and a free ball thing. Good stuff.