New Adventures in Software

I’ve just released version 0.9.0 of ReportNG, my reporting plug-in for TestNG. This version includes several improvements over the previous release. Most importantly, it addresses the biggest problem with the last version - the lack of information about configuration failures. Previously you had to increase the TestNG verbosity and dig around in the console output. Now config failures are displayed prominently above the test results.

There is also more information about skipped tests now too. Dependencies on groups and methods are listed for tests that have been skipped so that you can figure out why they were skipped.

• Sample HTML report (with some failures/skipped tests)
• Real-world example (hopefully with no failed tests)

Finally, aside from a few other cosmetic improvements to the HTML, I have introduce an experimental JUnit XML reporter. I had some problems getting the output that I wanted from the one bundled with TestNG. Mine generates one XML file per test class, which is closer to what you get from JUnit. Now you have the option of using whichever is most suitable for you (the default TestNG reporter or this one). The JUnit XML reporter should be considered incomplete (it doesn’t include detailed test case information yet), but it is useful enough for Hudson to generate summary reports.

If you have any feedback, either post a comment below or use the issue tracker.

This posting is brought to you via the magic of 44kbps dial-up Internet.

It’s now four days since my broadband connection suddenly stopped working. An hour of investigating routers, modems and phone lines revealed nothing. A telephone call to Pipex the next morning cleared-up my confusion. Pipex had cancelled my account. Not suspended, it was cancelled, which is apparently irreversible.

Why would they do this to me after over 3 years of a previously harmonious customer-ISP relationship? Because my debit card, which they had been charging every month, had expired four months previously. This was strange because back on 13th August they had sent me an e-mail threatening to disconnect me within 6 days because my card expired at the end of September (a little premature perhaps, but no worries because a phone call sorted it out and we arranged new payment details - or so I thought).

I’d completely forgotten about the summer’s confusion when I called up customer service again on Thursday morning to enquire why I couldn’t connect. Apparently, Pipex had continued to try to charge my card. It failed in September (no idea why since it was still valid) and it failed in October (by which time it had expired). Now rather than doing anything about it at this point (after all, the card was not going to become unexpired), Pipex attempted to charge the card again in November. Guess what? It didn’t work. Still, why not try again in December, just in case? Now it was at this point, on 18th December, that Pipex insists that they sent me an e-mail explaining the situation and outlining what would happen if I didn’t pay up. Somehow this e-mail never found its way to me. I’m not in the habit of randomly deleting e-mail (I still have the message they sent me on 19th December informing me of a change to the customer service phone number), but maybe this mail got lost in transit or got swallowed by an over-zealous spam-filter somewhere en route?

Anyway, I made the point to the helpful woman on the phone that it would have been much more constructive if Pipex had telephoned me or sent a letter to warn me of the impending disconnection. Even another e-mail on the eve of disconnection would have averted the situation. I was annoyed at the inconvenience but the woman told me I could pay the money owed and my connection would be back within 24 hours. Unfortunately, she couldn’t take my payment details but she’d put me through to someone who could. I didn’t appreciate having to wait 24 hours to get back online, but changing ADSL providers is a real headache, so you’ll put up with a lot of shit just as long as they get you connected.

So the helpful woman passed me on to the not-so-helpful man. I made my point again that the situation could easily have been averted with just a little bit more effort to contact me. He was entirely unsympathetic as he took my card details to pay for the previous 4 months and to set-up future payments. Great, so I’d be back online by the next day? No. It was going to take 48 hours, he said. I told him that I was not happy with this but I would make a complaint separately, and I thanked him for his cheerful assistance.

Now the best bit about having your account cancelled rather than suspended is that your mailbox is deleted. The 25 e-mails that I had read via web-mail but not yet downloaded were zapped and all subsequent mails to my address during this 48-hour period would be bounced. Brilliant.

48 hours passed. Still no Internet. Another phone call to Pipex and another unsympathetic call-taker. The woman seemed incredulous that I expected to get back online within 48 hours. This was going to take 7-10 days. My account hadn’t been suspended she reminded me, it had been cancelled! I’m not sure what the justification for such a delay is since, if I was a new customer, I would be online much more promptly.

It was at this point that I raised my voice for the first time. Again I made the point that the situation could have been avoided with better communication. I was informed that it was not their fault if I chose to ignore their single (apparently undelivered) e-mail. I told the woman that the situation was completely unacceptable and that I no longer wanted my account re-enabled. I asked for, and received, assurances that I would not be charged again and that my phone line was not locked by Pipex, so that I could use an alternative provider.

So that’s where we are. Waiting for the new ISP to set-up my ADSL connection, which, because of the weekend, is probably still going to be a few days. Pipex’s inflexible customer service turned a minor misunderstanding into a major inconvenience. They’ve gained yet another thoroughly dissatisfied customer and, without my business, they’ll have ever-so-slightly less money to piss away on David Hasselhoff and the under-performing players of Fulham FC. As for me, I’m getting a connection that is 4 times faster and costs less. And while I can’t vouch for the new ISP’s customer service, I feel confident that it can’t be any worse than Pipex.

Forget the shackles of backwards-compatibility. If you could make changes to Java to make it a better language, what would you do? I don’t mean drastic surgery so that you end up with Lisp on the JVM, but what could be done to make Java a better platform-independent, object-oriented language?

Bruce Eckel has some interesting thoughts about the evolution of Java and Sun’s commitment to backwards-compatibility. I have to agree that backwards compatibility will eventually kill Java if new features are continuously compromised by nasty hacks (e.g. erasure) to avoid breaking legacy code. At some point, the guardians of Java must choose new features or backwards-compatibility. To continue to demand both is not sustainable.

With this in mind, I’ve made a list of things that I personally would like to improve in Java, assuming that backwards-compatibility is not a primary concern. I’m interested to hear others’ suggestions, so leave a comment at the end if you have better ideas.

If it weren’t for Sun’s marketing department, we could have called it Java 2. Java++ is just wrong, so I’ll follow Cedric’s naming scheme and call it JavaNG - the next generation OO language for the JVM.

Maybe it’s just me, but this really bugs me…

Firstly, and it may seem trivial to most, but I would scratch an itch that has been bothering me for over a decade. The Cloneable interface does not define the clone method. An object must define a public clone method in order to be cloneable, but the Cloneable interface does not require this. Therefore it is perfectly legal to implement Cloneable yet not be cloneable. Of course, any class that does this is obviously broken, yet the Cloneable interface apparently cannot be changed since such a class would no longer compile. In my opinion, Sun would be doing developers a favour by making the compiler complain about this. FFS Sun, you broke everybody’s code by adding the assert keyword in 1.4, why would fixing Cloneable be such a big deal?

Is this an object-oriented language or not?

Right, now on to more substantial concerns. Primitives have to go. Everything should be an object. It would simplify learning the language and primitives don’t mix with generics without auto-boxing (and auto-boxing is horrific). No primitives - no auto-boxing - no problem.

I believe that primitives were originally included in the language because of performance concerns about doing everything with objects. Well virtual machines and hardware have both moved on significantly since the mid-90s. And if Ruby seriously is the main competition, then performance clearly doesn’t matter anyway.

BigDecimal.ONE.add(BigDecimal.ONE).compareTo(new BigDecimal(”2″)) == 0

Obviously if there are no primitives to unbox to, then the arithmetic operators have to be defined to work on the appropriate object types (java.lang.Integer, java.lang.Double, etc.). But why stop there? Arithmetic operators for BigInteger and BigDecimal are long overdue. Without first-class support for arbitrary-precision arithmetic, Java is not a sensible choice for many types of application. I mean, how hard should it be to assert that 1 + 1 = 2?

Types are for life, not just for compilation

I want generics without erasure. Since I can accept breaking backwards compatibility where necessary, I don’t have to accept a weaselly implementation compromise and the resulting frustrations of not being able to inspect type information at runtime.

Just say no to null

For a language that supposedly doesn’t have pointers, there are an awful lot of NullPointerExceptions in Java programs. The simple truth is that developers have proven to be incapable of keeping track of which references are allowed to be null. I want the language to do this for me. More specifically, I want the type system to do this for me. The Nice programming language has the concept of option types. I want one of those. If my method declares that its parameter cannot be null, then any attempt to pass it null (or even to pass it a value of a nullable type) should result in a compiler error. Non-nullable types will become the new ‘final fields’. They’ll be used everywhere unless there is a good reason not to.

Literal bias

Java’s verbose they say. Well Java will always look a bit wordy when compared to Python with its sleek dictionary syntax. But we could have that too. Literals for maps and lists would help to make code more concise and more readable.

Tuples

According to Gilad Bracha, Java was supposed to have had tuples from the start, they just never made it into the language. It’s time to rectify that. No more writing several trivial little classes (or generic Pair and Triple classes) just to wrap together multiple return values.

The stuff that didn’t make it…

I think that list is long enough for now (though I’m sure I’ll think of more later). You’ll notice that I haven’t taken a position on closures. I’m unconvinced and undecided. I need to read the proposals properly. In the past I’ve advocated first-class functions for Java, but for now I’m deferring on that too, at least until I’ve picked a side in the closures debate. I also think that the original Java designers got it right when they left multiple inheritance and operator-overloading in C++ land.

If you think you have a better plan for JavaNG, please add a comment. I’ll post a follow-up in a few days summarising the suggestions.