Syndicate this site: (RSS)

Adventures in Software Archaeology

package ntg ;
public class Foo
{
   public void put( Key k, Float f )
   {
      put( k, (Object)f ) ;
   }
   public void put( Key k, Object o )
   {
      // do something sensible with k and o
   }
   // remainder of the class elided
}

Why does put( Key k, Float f ) exist today?

I tripped over this one today which experimenting with some tests.

java.lang.Float IsA java.lang.Number IsA java.lang.Object. So one possibility is that, hidden elsewhere, is a put overload that accepts a Number for the second argument, and that the behavior is not appropriate for Float. Not terribly likely.

I think the other is more likely - once upon a time, put(Key k, Float f) needed behavior distinct from put(Key k, Object o). If a client is compiled against that overload, when you remove the overload the result is a mess - at run time, the old client can't find the function that it is bound to, and you have a mess (java.lang.NoSuchMethodError see JVM Spec).

Of course, the only clients of this class are in the same project, so that shouldn't be an issue. I'm guessing that, when put(Key k, Float f) was reduced, the author initially tried to remove the function, ran the UnitTests (yes, the class actually had some), and - when the tests failed miserably - put the redundant overload back rather than investigating the failure to learn what was wrong.

Is there any corroborating evidence? I've not looked at the file history, but did note in passing yesterday that the original project file I was handed had "compile on debug" disabled. . . .

February 26, 2003 8:19 PM | TrackBack

Comments
Post a comment




Who are you?