I decided to buy a certification exam voucher at Christmas and for the last three months I have been doing a lot of studying for the exam. This morning there was a lot of trepidation as I made the trip to the assessment centre, not least because I paid for the test out of my own pocket and didn’t want to throw more money at retaking it.

I used three main methods of preparation: Sun’s own web-based practice exams, Sybex’s study guide and the excellent Examulator by Marcus Green. All three had their own virtues, Examulator was actually closer to the final exam format while the Sun practice exams had really good questions but were very pricey with only three mock exams all of which had to be taken in six months.

The Sybex book was spot on with its information; everything you need to know is in there and the example questions at the end of each chapter are good. However you need to check the errata and some sections are much better written than others. A particularly poor section is the explanation of Enums, it was only in the last week (via Examulator) that I discovered an Enum can be used anywhere a class is (I knew Enums where equivalent to classes but hadn’t made the connection) and therefore you could have inner and method Enums. All very odd and disturbingly last minute.

I knew when I started the exam that it would contain question formats and a UI that would be unfamiliar and that worried me. Also despite the geek stories of how easy the exam is and how so and so got 90% the first time they tried it after just three weeks revision I was fully expecting to fail the first time. After all this is meant to be some kind of global Java gold standard. I decided before I went in that I would make full use of the Mark and Review functionality and go for a first pass that would weed out the easy points. That technique definitely worked for me and settled me into the format and gave me some confidence to tackle the harder questions.

As for the questions you are not allowed to say too much (and it is not in your interest frankly to lower the bar for everyone else) but as someone who works with 1.4 day to day I found the 1.5 specific stuff (like Scanners, formatted printing and Templating/Generics code) harder because the reinforcement for the theoretical stuff just wasn’t there. Some of the drag and drop logic puzzles were very tricky and in the end for a few I had to just start playing around and eliminating some of the options to avoid analysis paralysis. I was also impressed how much stuff had been drilled into me about method overriding, variable scoping and Concurrent programming. I’m not sure how much of the certification course will come in handy in my regular work but I do now feel I have the confidence to go and do the consultant thing of looking at a bad piece of code, figure out what it is doing and how.

Why? Well obviously because I passed the test, I practically ran to the reception desk where the result was printed out and the minute someone said “congratulations” I just sagged with relief. Becoming Certified was a major goal I set myself this year and I have spent a lot of time, effort and money realising it. It feels fantastic to have achieved it more or less on time.

Of course what feels even better is that for the next few months my Sundays will not have to be centred around two hours of practice exams and when I take a book to bed it isn’t going to be the certification guide or Java in a Nutshell. From now on I can rely on the IDE to tell me what the API content is between version 1.4 and 5.0, hurrah!

I feel like I am getting my life and my free time back and that makes this achievement all the sweeter. After university I swore never to take an exam again and ten years isn’t a bad run to have stuck to a resolution. However the truth is that with globalisation competition for work in IT is still incredibly fierce despite the paucity of skilled labour in the UK. Certification is one of those things that shows you are willing to go that little bit further than the next candidate. Right now though the self-achievement is enough, the adulation can wait…

Okay, I have to admit I am really starting to like NetBeans 5.5. Projects transfer between Mac and PC fine. You can put the projects onto a USB drive and work on them with no real issues or noticeable slowdown for the dinky projects I have. I also downloaded the Eclipse project importer and hell, it just worked.

As I’ve said before Eclipse 3.2 is still in Beta but I suspect that while it will remain a great Windows IDE NetBeans is probably going to be a vital accompaniment from now on.

Or rather Inter-Package Inheritance Part 2, as last time I got caught up in my circular dependency WSAD rant. So what does Inter-Package Inheritance allow? As far as I can see; bugger all. After all if a package in a collection of coherent functionality then how on earth can separating the implementation of something across multiple places be good?

But on the other hand what harm can it do? Well firstly it makes it bloody hard to find out what is happening with a given piece of code in the usual inheritance way. Namely which method is actually executing, which variable is getting updated and are those the methods and variables that should be getting touched. I also find it particularly hard to have to trace up a hierarchy of three classes just to find out what the full set of variables a particular object should have.

But the killer feature that Inter-Package Inheritance has over normal inheritance is that once you’ve made an unfinalised class with protected instance variables and methods accessible then practical refactoring is a nightmare. The root class can be in use anywhere and is effectively lava-flowed. The inheriting objects are similarly rooted as even though they may represent discrete functionality they always need to be able to read their parent objects.

This has had some weird implications in my current job (for example because there is a dependency on the GNU Regexp class somewhere in the “common” code all the projects need to import it into the classpath, even if they don’t use the class or the package anywhere else) but also lead to my circular build wreck. I moved the factory but the objects it served out had to stay in the lava flow because their parents were (incorrectly I may add) in the EJB layer. This lead to a dependency circle where the factory (in the business layer) depended on the EJB layer which depended on the factory. In addition the client layer (which resides in the shared object layer, natch) also depended on the factory and the EJB layer also depends on shared layer.

So what does this gibberish mean? Well everything basically bloody depends on everything else. and the most frustrating thing is that this has all arisen because someone wanted to inherit a few instance fields rather than encapsulating and compositing them like normal.

Actually I say like normal but this seems a relatively common kind of problem so I turn (by the power of Safari) to Fowler’s Refactoring for advice but he doesn’t seem to have a magic bullet. I can see the problem but collapsing the hierarchy is probably going to be major work because the package hierarchy is not just split between packages, it is also split between ClearCase/WSAD projects one of whom is read-only in the normal composite stream.

The answer perhaps lies in doing some selective duplication in the supporting business layer. Creating objects to represent the inherited instance values, one root class to provide the default class implementations that may be required for backwards compatibility and then switching the affected classes to use these new objects that exist in their own project space (or at least in their immediate project space). Still this is not a trivial change that you can skip past the management one Friday afternoon and that means some kind of detailed plan of action.

I always feel that if you present a correction plan and it gets turned down then you’ve done your professional duty (and covered your arse if you are so inclined) and you can carry on with a clear conscience. Here though there are so many things wrong in so many areas so corrective action may need to be taken sooner rather than later.

Okay so we know that inheritance is bad and that inter-package inheiritance is even worse but just because you know that doesn’t mean that you don’t have to deal with it. The latest Gordian Knot at work is project dependencies within WSAD projects but the root cause is, I suspect, a dangerous infatuation with inheritance as a solution for everything.

The problem I had was trying to share functionality between an EJB client and server layer. Logical solution: introduce a new project that contains all the common functionality and simply make the existing projects use that as a dependancy. However the pervading view of “nothing new” that afflicts my workplace got to me and I decided instead to try and just massage the functionality of the existing projects.

When I merged my work in ClearCase the .classpath file blew up and wouldn’t parse. Since these files are “secret” Eclipse project files it can be bugger to get them back into a workable state. In this case I could get the file to be to be valid XML but it still wouldn’t work (probably because it couldn’t reconcile to something else in the Workspace like the Project Set or the project file). In these cases I’ve always just created an entirely new classpath file for the project. In fact having your project files blow up can be a good chance to see what exactly your code does and doesn’t need.

Having the classpath blow up can be a huge warning sign as well. The project I work on has about 5000 to 20000 warnings depending on the level of concern you want to set. Usually I like to work with very strict warning levels but in this case it did me no favours because after I reconstructed my class path I completely failed to notice the significance of the circular build warnings that appeared.

Visually this is a major flaw in WSAD, a circular build dependency is actually a bigger issue than an unused method parameter but visually they are identical in the WSAD Task pane. I am also a little surprised that it is only a warning.

WSAD can resolve the dependency by stacking build requests; building one project until it gets a dependency then building the dependent project until it gets another dependency then asking the original project to be built and then unwinding the stack of building requests. It adds a little extra time to the full build time but compared to the huge amount of time required by a full enterprise build it is very hard to notice any change and in fact it seamlessly resolves most project linking issues allowing you to be very generous in creating project dependencies and using larger workspaces.

My problem is that there is a headless build script that is used during the construction of an application from a given ClearCase baseline and this headless build (despite being nominally an identical process to the WSAD GUI build) cannot seem to stack build requests in the same way and thus the circular dependency kills the build script. The pain of WSAD headless builds is a topic for another post but the script’s failure introduces yet another dependency as the build script is now defining the structure of the projects in the application. If the build script cannot work with the changes you make in WSAD then the code overall is deemed to fail.

This is more process than technology but it still adds to the general sensation of being more of a magician spinning plates when working with large, legacy EJB apps in WSAD than any kind of professional programmer.