Archive for category Java

More pastry for the Android


Our mascot received a new companion today.

Next Generation Java is not very different from today's Java

In a recent post, Stephan Schmidt makes several suggestions in order to write “Next Generation Java”. Unfortunately, I disagree with most of them… Let’s take them in turn:

final everywhere

This is guaranteed to make your code littered with final keywords and therefore, impair readability significantly (same problem as Python’s self pollution). And it really doesn’t buy you that much, I can’t even remember last time I was bitten by a bug involving the reassignment of a variable to a different value within a code block. For what it’s worth, final on non fields is banned from Google’s style guide (except where it’s unavoidable, such as when you need to pass variables to inner classes).

No Setters

It would be nice, but it’s just not realistic. Sometimes, you really don’t want to put that many parameters in a constructor (and the Builder pattern doesn’t solve this problem either). Besides, it’s convenient to be able to mutate object if you want to use pools. As for not using accessors overall, Stephan is not the first one to argue that they should be removed from OO programming overall, but this claim is easily debunked.

No loops

Java is not very well suited to a functional style, so I think the first example is more readable than the second one that uses Predicates. I’m guessing most Java programmers would agree, even those that are comfortable with comprehensions and closures and especially those that aren’t.

Use one liners

Depends. Sometimes, breaking down the expression and introducing variables clarifies the intent of the code and it also makes it easier to use break points.

Use objects with interfaces

A good advice overall, but don’t go overboard. I have argued something similar in the past under the name Quantum Software Design but introducing too many interfaces can result in an explosion of little classes that cloud the intent of your high level classes.

Erlang concurrency

Again, it’s dangerous to use a programming style that Java was not designed for. java.util.concurrent is a treasure trove of very useful constructs and I’d rather see a set of well architected Java abstractions built on top of it than an emulation of Erlang’s actor architecture.

Fluent interfaces

Now that’s an interesting recommendation since it contradicts directly Stephan’s suggestion of not using setters, because make no mistakes: fluent interfaces are setters in disguise. So, Stephan, which one is it? :-)

Use public fields

No. Just, no. You will never regret adding accessors to your classes if you need the data, but I can promise you that you will rue the day where you decided to be lazy and to make a field public.

Splitting the atom is hard, splitting strings is even harder

I always seem to underestimate how much readers of this blog enjoy a good coding challenge. A few days ago, one of my coworkers was tripped by a line of code and I thought I’d share his confusion with people following me on Twitter, which turned out to be a fitting medium for this micro challenge:

Pop quiz: "abc.def".split(".").length should return...?

I really didn’t think much of it but I got much more responses than I anticipated. A lot of them were incorrect (hey, if I throw a challenge, there has to be a trick), but I still want to congratulate everyone for playing the game and answering without testing the code first. That’s the spirit!

A few people saw the trap, and interestingly, they pointed out that I must have made a mistake in the question instead of just giving the correct answer (“You must have meant split(“\\.”)”).

As hinted above, the trick here is that the parameter to java.lang.String#split is a regular expression, not a string. Since the dot matches all the characters in the given string and that this method cannot return any character that matches the separator, it returns an empty string array, so the answer is “0”.

This didn’t stop a few people from insisting that the answer is “2”, which made me realize that the code snippet above happens to be valid Ruby code, a pretty unlikely coincidence. So to all of you who answered 2 because you thought this was Ruby, you were right. To the others, you are still wrong, sorry :-)

The bottom line is that this method is terribly designed. First of all, the string confusion is pretty common (I’ve been tricked by it more than a few times myself). A much better design would be to have two overloaded methods, one that takes a String (a real one) and one that takes a regular expression (a class that, unfortunately, doesn’t exist in Java, so what you really want is a java.util.regex.Pattern).

API clarity is not the only benefit of this approach, there is also the performance aspect.

With the current signature, each call to split() causes the regular expression to be recompiled, as the source sadly confirms:

public String[] split(String regex, int limit) {
return Pattern.compile(regex).split(this, limit);
}

Since it’s not uncommon to have such parsing code in a loop, this can become a significant performance bottleneck. On the other hand, if we had an overloaded version of split() that accepts a Pattern, it would be possible to precompile this pattern outside the loop.

Interestingly, that’s how Ruby implements split():

If pattern is a String, then its contents are used as the delimiter when
splitting str. If pattern is a single space, str is split on whitespace, with
leading whitespace and runs of contiguous whitespace characters ignored.

If pattern is a Regexp, str is divided where the pattern matches. Whenever
the pattern matches a zero-length string, str is split into individual
characters.

But there is a catch: since Ruby is dynamically typed (which means it doesn’t support overloading either), the determination of the class of the parameter has to be done at runtime, and even though this particular method is implemented in C, there is still an unavoidable performance toll to be paid, which is unfortunate for such a core method.

The conclusion of this little drill is that if you are going to split strings repeatedly, you are better off compiling the regular expression yourself and use Pattern#split instead of String#split.

Soft asserts

A question that has come up a few times already on the TestNG list is how to use asserts that won’t abort the entire test method.

Here is the latest example:

@Test
public void verifyUi() {
  selenium.open (/* url */);
  assertTrue(selenium.isElementPresent("id=txtfiled"));
  assertTrue(selenium.isElementPresent("id=submit"));
  assertTrue(selenium.isElementPresent("id=drpdwn1"));
  assertTrue(selenium.isElementPresent("id=radiobtn"));
}

The author would like each of these asserts to be run, even if one of them fails.

A simple solution to this problem is to use boolean tests to gather the state of each test and then have a final assert that will test them all:

boolean el1 = selenium.isElementPresent("id=txtfiled");
boolean el2 = selenium.isElementPresent("id=submit");
boolean el3 = selenium.isElementPresent("id=drpdwn1");
boolean el3 = selenium.isElementPresent("id=radiobtn");
assertTrue(el1 && el2 && el3 && el4);

The downside of this approach is that if the test fails, you won’t know exactly which element was not found on your web page, so we need to find a solution that will also provide a meaningful failure message.

Here is a more flexible way to approach this problem. It introduces a method assertSoft() that doesn’t throw any exception in the case of failure but that records the message if the test didn’t succeed. Error messages are accumulated in this variable, so it can contain more than one failure report.

Finally, a real assert method verifies that the error message is empty and throws an exception if it’s not:

public void assertSoft(boolean success, String message, StringBuilder messages) {
  if (!success) messages.append(message);
}

public void assertEmpty(StringBuilder sb) {
  if (sb.length() > 0) {
    throw new AssertionException(sb.toString());
  }
}

@Test
public void elementShouldBePresent() {
  StringBuilder result = new StringBuilder();
  assertSoft(selenium.isElementPresent("id=txtfiled"), "Couldn't find txtfiled ", result);
  assertSoft(selenium.isElementPresent("id=txtfiled"), "Couldn't find submit ", result);
  assertSoft(selenium.isElementPresent("id=txtfiled"), "Couldn't find drpdwn1 ", result);
  assertSoft(selenium.isElementPresent("id=txtfiled"), "Couldn't find radiobtn ", result);
  assertEmpty(result);
}

Can you think of a better way to solve this problem?

Why Java doesn't need operator overloading (and very few languages do, really)

Operator overloading is a topic that never fails to generate very passionate responses, and this monster thread on Artima is no exception.

First of all, I’d like to address a common complaint heard from people who dislike operator overloading, and which usually goes along the lines of:

In Java, when I see a + b, I know exactly what is going on. If Java supported operator overloading, I would have no idea what + means.

I have very little sympathy for this argument because this example is hardly different from a method call such as o.init(). When you read such code in Java, you don’t necessarily assume that it’s the method init on o‘s class that is being invoked. You know that you will have to look at how this object is created in order to determine its effective type before you can find out which method init is being invoked.

Operator overloading is no different, and if you knew that the language that you are reading supports it, you are just going to extend this mental path to operations that involve overridable operators.

Very often, I find that operator overloading is being demonized because its uses in other languages has led to excesses. I have found that many people who dislike operator overloading can trace it back to some personal experiences where they once had to deal with code that was clearly abusing this feature. This is unfortunate, but I still think that Java is doing fine without it and that overall, it only leads to clearer code in very few and uncommon cases.

Here are a couple of objections I have with operator overloading:

  • The number of operators that you can overload is very small and each of them is attached to very specific semantics that makes little sense outside the realm of scalars and of a few other specialized mathematical concepts (e.g. matrices).

  • In exchange for infix notation, operator overloading severely restricts my freedom to name my methods in a meaningful way.

The most common operators that people want to overload are + and -, and they are also the operators that probably make the most sense outside simple arithmetics. I can see these two operators make sense for types that represent a collection of elements (java.util.Collection obviously, but also strings or streams). However, even in this ideal case in favor of operator overloading, the metaphor quickly breaks down when you realize that you need to supplement these two methods with ones that have slightly different meanings, such as addAll(). Would you rather have an interface that contains add() and addAll() or +() and addAll()?

Of course, there are more operators that can be overloaded, such as * or /, but I find that even strong advocates of operator overloading quickly run short of arguments when trying to justify why one would even want to overload them outside of specific algebras.

I am a big fan of clear names, and I dislike the name + for the simple reason that it doesn’t carry enough meaning to explain to me what is going on. This operator is very clearly defined when it is used in a mathmatical sense but it becomes very vague when you start to extend it to concepts that supports the idea of addition in a more vague sense. For example, adding to a List is very different from adding to a Map since the latter can produce an object that’s equal to the one you started with, even though the object you added is not zero. And what is zero in the sense of a collection, anyway? Doesn’t it make much more sense to use add() for a List and put() for a Map?

Overall, I find that code that makes heavy use of operator overloading is harder to read and harder to maintain because it is severely restricted syntactically (forced to use specific names taken from a very small pool) and semantically (since you are using symbols that have very precise mathematical definitions, it is very unlikely that your usage will match the mental model that people who read your code have of their meaning).

I would love to see some good examples of operator overloading, if you have any to share…

Announcing TestNG 5.9

I’m happy to announce the release of TestNG 5.9. A lot of bug fixes went into this release, and a few noteworthy new features:

  • Parallelism can now be specified on classes. In the previous versions, you could specify either a setting of "methods" (every test method will be run in its own thread) and "tests" (all the methods in a given <test> tag will be run in the same thread but each <test> tag will run in its own thread). The new "classes" setting extends this functionality to test classes: all the test methods in the same class will run in the same thread but each class will have its own thread. Of course, the thread pool size and time out for these three settings are configurable.
  • You can now specify a time-out on @Test methods that use the invocationCount attribute. This way, you can specify that a test method should be invoked fifty times but that the maximal time allowed for these fifty invocations is ten seconds. If the invocations don’t complete in time, the test will be marked as failed.

  • A few new interfaces to assist developers who use the TestNG API: IAnnotationTransformer2 extends the annotation modification capabilities to more than just @Test and IInvokedMethodListener, which gives you additional monitoring on what test method is being invoked and when.

A lot of people have contributed patches, fixed and improvements for this release, and their names can be found in the full release notes below. Thank you all!

Release notes for TestNG 5.9

  • Added: New ant task boolean flag: delegateCommandSystemProperties (Justin)
  • Added: skipfailedinvocations under <suite> in testng-1.0.dtd (Gael Marziou / Stevo Slavic)
  • Added: -testrunfactory on the command line and in the ant task (Vitalyi Pamajonkov)
  • Added: TESTNG-298: parallel="classes", which allows entire classes to be run in the same thread
  • Added: @BeforeMethod can now declare Object[] as a parameter, which will be filled by the parameters of the test method
  • Added: IAnnotationTransformer2
  • Added: @Test(invocationTimeOut), which lets you set a time out for the total time taken by invocationCount
  • Added: IInvokedMethodListener
  • Added: -testjar supports jar file with no testng.xml file
  • Fixed: IInvokedMethodListener wasn’t properly recognized from the command line (Leonardo Rafaeli)
  • Fixed: TESTNG-309 Illegal default value for attribute in DTD file
  • Fixed: TESTNG-192: JUnit XML output includes wrong tests (Aleksandar Borojevic)
  • Fixed: Set a generated suite to default to non-parallel (Mark Derricutt)
  • Fixed: -testJar command line parsing bug
  • Fixed: testng-failed.xml didn’t include the listeners
  • Fixed: annotation transformers were not run when specified in testng.xml
  • Fixed: TESTNG-192: JUnit XML output includes wrong tests (Borojevic)
  • Fixed: @Parameters was not working correctly on @BeforeMethods with @DataProvider used on @Test methods
  • Fixed: testng-failed.xml was sometimes incorrectly generated (Borojevic)
  • Fixed: TESTNG-228: Assert.assertEqualsNoOrder
  • Fixed: TESTNG-229: Assert.assertEquals does not behave properly when arguments are sets
  • Fixed: TESTNG-36: assertEquals(Collection actual, Collection expected, String message) may have bug
  • Fixed: TESTNG-296: Malformed jar URLs breaking -testJar
  • Fixed: TESTNG-297: TestNG seemingly never stops running while building failed test suite (Gregg Yost)
  • Fixed: TESTNG-285: @Test(sequential=true) works incorrectly for classes with inheritance
  • Fixed: TESTNG-254: XmlSuite toXML() ignores listeners
  • Fixed: TESTNG-276: Thread safety problem in Reporter class
  • Fixed: TESTNG-277: Make Reporter.getCurrentTestResult() public
  • Fixed: Potential NPE in XmlTest#getVerbose (Ryan Morgan)
  • Fixed: EmailableReporter only displayed the first group for each test method
  • Fixed: time-outs were not working in <test> and <suite>
  • Fixed: @BeforeTest failing in a base class would not cause subsequent test methods to be skipped
  • Fixed: TESTNG-195: @AfterMethod has no way of knowing if the current test failed
  • Fixed: TESTNG-249: Overridden test methods were shadowing each other if specified with <include>
  • Fixed: DataProviders from @Factory-created tests were all invoked from the same instance
  • Fixed: enabled was not working on configuration methods
  • Fixed: IIinvokedMethodListener was not correctly added in TestNG
  • Fixed: NPE in XmlSuite#toXml
  • Fixed: TESTNG-231: NullPointerException thrown converting a suite to XML (Mark)

Guido on Scala

Guido took a look at Scala recently and he came out a bit intimidated by the language, which matches my perception. I initially started with quite a lot of fondness for Scala but as I dug deeper in the language, the complexity and a few specific features started to worry me.

I have been following the Scala mailing-list for a few years now and the snippets of code I read on a daily basis have been increasingly complex and frightening, and it’s taking me more and more time to make sense of them. Not a good sign.

Anyway, read Guido’s take and especially the comments. Here is one I found particularly interesting, from David Pollak, the creator of Lift:

But, unlike my Ruby code, [with Scala] I only need 50%-60% test coverage (vs. 95% coverage) to have stable, deployable code.

This is an angle that I have often been defending in the debate that pits statically against dynamically typed languages, but it’s the first time that I come across such strong evidence.

Android Translate

My modest contribution to the ever-growing Android Market is Translate, an application that uses Google’s back-end to translate over 150 language pairs. I wrote it pretty quickly, just as a proof of concept and also to see how it feels to use the “real” (public) SDK, as opposed to the internal builds that I’ve been using these past two years.

Considering the simple scope of this application, slapping a simple UI on top of some HTTP exchanges with the Google Translate API was fairly trivial. Translate was downloaded more than 10,000 times so far and the comments are very positive (and sometimes downright hilarious).

The most surprising part to me is how few users seem to realize that Translate actually uses Google Services to do its job, and then it occurred to me that it’s one of the first times where the code that I write actually gets used by non-technical people (with the exception of Gmail for Java ME and Gmail for Android, which also taught me a lot about our audience).

Before I uploaded the application to Android Market, I also decided to make it easy for users to reach me, so not only did I leave my email address in clear text, but I made it possible to send me an email pretty much with just one button. I thought it was a bit risky since I could find myself flooded with emails, but I
decided that Gmail would make it easy for me to filter out such emails anyway.

I have received over fifty emails so far, and most of them are to say how much they like the application and are also asking for additional features, such as:

  • More languages.
  • Make it possible to send the translation by email or SMS.
  • Allow the history to be cleared.
  • Hook it up to other applications so that users can, for example,
    translate emails they receive.

I’ll be addressing most of these requests in the next version, but in the meantime, I’m learning a lot from this little social experiment. Oh, and if you are curious or you wish to contribute to this application (and a bunch of others), you can find its source on Google Code.

Jazoon presentation available online

The presentation I gave at Jazoon is now available online. It suffered a bit from the converstion to PDF, but it’s still readable. Note that I tend to write slides with less text and bigger fonts, so a lot of the content is not captured in these slides, but this will be enough to give you an idea.

In this presentation, I gave a fast and furious tour of the programming languages that you have seen on front pages recently, some of which are seen as potential successors to Java. I also make the point that despite these claims, I don’t see any language dethrone Java for a very long time. My prediction is that Java will keep cherry picking the best features from all these languages and continue to adapt to meet the challenges of tomorrow, either at the language level (unlikely to change much) or via frameworks (much more likely).

Jazoon'08

I will be speaking at Jazoon next week. This will be a brand new presentation called “A quick guide to modern languages and interesting concepts for the busy Java programmer”.

Here is the description:

A lot of new languages have emerged to challenge Java these past years: Ruby,
Scala, Groovy, Erlang, etc… Can Java survive? In this presentation, I will do
a quick analysis of these various languages and explain why, despite its old
age, Java is in the best position to face the challenges that await software
developers for the next decade. I will cover topics such as dynamic and duck
typing, functional programming, concurrency, distribution and much more.

As you can see, the topic is very broad and the main challenge will be to keep the presentation within the allotted time. Hopefully, we’ll be able to carry on the discussion over beers or dinner.

See you all in Zurich.