[Gusdev-gusdev] import statement policy

[Steve F. <st...@pc...>]

folks-

during jonathan crabtree's last code review at our CBIL lab meeting, we 
had a little discussion about Java's import statement, in particular, 
whether its ok to use an asterisk.  with renewed vigor, i want to sell 
the idea that i don't think it is. (tomatoes are invited)

I have been gearing up to start coding in crabtree's servlet/WDK world 
and to do so i have had to take a comprehensive tour.  it has been clear 
that this has been more difficult because of the obscuring of what class 
comes from what package.  Here is a typical import statement (from the 
file AllgenesPageFormatter.java):

import cbil.csp.*;
import cbil.gus.servlet.*;
import cbil.gus.servlet.db.*;
import cbil.gus.servlet.pages.*;
import cbil.gus.servlet.util.*;
import java.io.*;
import java.sql.*;
import java.util.*;
import javax.servlet.http.*;

This file refers to a bunch of classes that are new to me, and, as i am 
trying to understand what is going on, i have to go visiting.  But, each 
time i do so, i have to wade through all those packages to try to figure 
out where the class lives in order to visit it.  sometimes i can guess, 
and sometimes i can't

The arguments excusing the asterisks were:
  1. if we have javadocs, then they resolve the package and you can link 
to the class.  But, that is only helpful if, indeed, we have a  javadoc 
and if we are perusing an API not the actual code.

  2. it is a hassle to include the full path in the import statements.  
in my experience, this is not so.  if you don't use asterisks, then the 
compiler will complain about any unmentioned classes, so you just plop 
them in as part of getting the class to compile.  also, it is typically 
the case that we only use a small number of classes per package so the 
number of import statements is not that much bigger.

3. it is hard to maintain because the compiler doesn't complain about 
import statements that are no longer needed.  yes, but it doesn't matter 
that much of there are irrelevant import statements.  and, if the import 
statements have the full path, it is quite easy to perform a periodic 
cleanup by just marching through the import statements and making sure 
the classes are mentioned in the code below.  on the other hand, a 
package statement with a * is very hard to purge if it is not needed, 
because you have to survey each class mentioned in the file to see if 
the package is still used.

so, my proposal is that -unless i find myself dripping with tomato- code 
that we review should have fully qualified import statements.

steve