Unused parameters in the JDK

11 Jul 2006

Here's another entry along the same lines as 'try without catch in the JDK'. After making some enhancements to PMD's unused parameter rule I ran it on the JDK source to see what turned up. This rule only checks private methods since public methods frequently have unused parameters due to interface implementation requirements. Anyhow, here are some notes:

  • java.net.URI has a resolvePath method that take three params, the third of which, absolute, is unused. It's a little strange because the method seems to sort out whether or not the path is absolute or not on its own:
    if ((cp.length() > 0) && (cp.charAt(0) == '/')) {
      // 5.2 (5): Child path is absolute
      ru.path = child.path;
    } 
    This method is only used once and it's passed a calculated value in the third parameter, so removing that parameter from it and from the method invocation would probably save a few cycles.
  • java.io.FileSystem has an odd getBooleanProperty method that takes a String parameter prop and a boolean parameter. Strangely, the String parameter is unused and in the spot where I'd expect it to be used there's this:
    String val = System.getProperty("sun.io.useCanonCaches");
    This method also uses this wordy construct:
    if (val.equalsIgnoreCase("true")) {
      return true;
    } else {
      return false;
    }
    Which could be boiled down to this:
    return val.equalsIgnoreCase("true");

    PMD's SimplifyBooleanReturns rule will find those cases; good times.

  • java.security.Security has a doGetImpl method that takes a String algorithm as the first parameter; this parameter is unused. It looks a little weird since the method throws both NoSuchAlgorithmException and InvalidAlgorithmParameterException, but anyhow, the algorithm name seems to be encoded in the second parameter which is a String named type.

Another example that turns up in a few places is related to serialization. Some classes declare the private writeObject method but they just throw an exception rather than using the ObjectOutputStream parameter. Might be worth adding an exception to the rule for this method name since that's effectively a false positive...

For much more along these lines, get the PMD book!