Molindo Techblog

Wicket’s RepeatingView is a very handy component: You can add as many components as you want. As a result, the usage of this component differs from other, as you don’t add components using html tags with a wicket:id attribute. Instead, IDs are generated by incrementing a number and convert it to a string. The RepeatingView even offers a nice helper method to generate those IDs. Basically, this method does nothing else than

public String newChildId() {
  return Integer.toString(childIdCounter++);
}

But the folks behind Wicket seem to work more carefully than I do:


/**
 * Generates a unique id string. This makes it easy to add items to be rendered w/out having to
 * worry about generating unique id strings in your code.
 *
 * @return unique child id
 */
public String newChildId()
{
  childIdCounter++;
  if (childIdCounter == Long.MAX_VALUE)
  {
    // mmm yeah...like this will ever happen
    throw new RuntimeException("generateChildId() out of space.");
  }

  // We prepend the id's with the text 'id' so they will generate valid
  // markup id's if needed.
  return String.valueOf(childIdCounter);
}

But does it really make sense to check whether Long.MAX_VALUE (2⁶³-1 or 9,223,372,036,854,775,808) was reached? The developer doesn’t believe so, but seems to work carefully … or overcautious? … or just paranoid? Well, let’s do the maths:

As already an empty string object has 40 bytes (x86 processor, Sun JVM), creating this number of empty strings would require more than 325.000 petabytes of memory.

But even if the objects are left for garbage collection, calling this method Long.MAX_VALUE times takes ages. I tested the same method with Integer.MAX_VALUE (2³¹-1 or 2,147,483,647) on my Pentium M 1.86GHz and it took 14 minutes to hit the RuntimeException. As It would take 2³² times longer to reach Long.MAX_VALUE, it would approximately take 114,401 years. Quite a long time to construct a web page, eh?