Time-zone database - Astrolabe withdraws

Just a quick blog to say that the lawsuit against the time-zone database appears to be at an end.

PLAINTIFF'S NOTICE OF VOLUNTARY DISMISSAL
WITH PREJUDICE & WITHOSUT COST
Pursuant to Federal Rule of Civil Procedure 41(a)(1), please take
notice that Plaintiff ASTROLABE, INC., pursuant to Federal Rule of
Civil Procedure 41(a)(1), hereby voluntarily dismisses all claims in
this action with prejudice, and without costs, as to Defendants ARTHUR
DAVID OLSEN and PAUL EGGERT.

In connection with this NOTICE, the Plaintiff states that the
Defendants have neither answered Plaintiff's Complaint, nor filed a
motion for summary judgment. Accordingly, this matter may be
dismissed with prejudice and without an Order of the Court.

The EFF had this to say:

The Electronic Frontier Foundation (EFF) is pleased to announce that a copyright lawsuit threatening an important database of time zone information has been dismissed. The astrology software company that filed the lawsuit, Astrolabe, has also apologized and agreed to a 'covenant not to sue' going forward, which will help protect the database from future baseless legal actions and disruptions.
...

In a statement, Astrolabe said, "Astrolabe's lawsuit against Mr. Olson and Mr. Eggert was based on a flawed understanding of the law. We now recognize that historical facts are no one's property and, accordingly, are withdrawing our Complaint. We deeply regret the disruption that our lawsuit caused for the volunteers who maintain the TZ database, and for Internet users."
...

"We are grateful that EFF and its co-counsel at Fish & Richardson were able to step in and assist us, so that we could help ensure the TZ database would continue to be available," said Eggert and Olson.

So in the end, Astrolabe understood that facts cannot be copyrighted and withdrew the case. I am also glad to see their statement of regret.

Finally, its good to see the EFF's positive involvement in the case.

JDK helper Math methods

Update 2013-08-16: The three methods discussed below - incrementExact, decrementExact and negateExact - have all made it into JDK 8.

How far should simple helper methods go in the JDK? Specifically for Maths.

JDK helper Math methods

A discussion is occurring on the OpenJDK core-libs list to provide some maths helper methods. But there is a disagreement as to which methods should be provided.

The following methods appear to be going in (to java.math.Math, as static methods):

• addExact(int, int)
• subtractExact(int, int)
• multiplyExact(int, int)
• toIntExact(long)

All the methods are intended to throw an exception on overflow, so you would use addExact instead of a + b if you care that the result fits into an int.

Furthermore, some of these methods are designed such that the JVM may be able to provide better low-level implementations dependent on the processor. The same methods with long as the parameter type are also included.

The discussion has arisen around some additional methods:

• negateExact(int)
• incrementExact(int)
• decrementExact(int)

These are currently going to be rejected on the grounds that "they don't pull their weight in the API". So, this blog post is to canvas a wider opinion.

The proposed alternatives are either that the caller should just write the code themselves, by testing against Integer.MIN_VALUE, or to indirectly use one of the other methods. (If you're wondering how negating an integer could go wrong, read this.)

So, here are the three discussed options for negation:

  int x = ...
  
  // option A - dedicated method
  int a = Math.negateExact(x);
  
  // option B - code at the call-site
  if (x == Integer.MIN_VALUE) {
    throw new ArithmeticException();
  }
  int b = -x;
  
  // option C - indirectly use another API
  int a = Math.subtractExact(0, x);

And here are the options for increment:

  int x = ...
  
  // option A - dedicated method
  int a = Math.incrementExact(x);
  
  // option B - code at the call-site
  if (x == Integer.MAX_VALUE) {
    throw new ArithmeticException();
  }
  int b = x++;
  
  // option C - indirectly use another API
  int a = Math.addExact(x, 1);

For me, I find option A in both cases to be a lot clearer when reading the code, as it says three things - that I have understood the corner case, done something about it, and documented that thinking via the inserted method. Sure there is more code in the library (the JDK) to enable this, but isn't that really the point of libraries? To provide the common code so we don't have to? The alternatives are far less appealing to me.

The counter argument is that the more methods that the JDK provides, the harder it is for users to find things. And the JDK gets larger (bigger jar file) as a result.

So, dear reader, its over to you :-) How far is too far when adding methods to the JDK? Should negate, increment and decrement be provided in the JDK to help protect us against errors, or can/should we use the alternatives above?