Well, Scott Stanchfield had started some work on this -

http://www.javadude.com/tools/importifier/index.html

Also here is my post from few months ago -

 There is a perpetual controversy about wild card vs specific
 imports :

 import java.awt.*;

 vs

 import java.awt.Frame;
 import java.awt.Panel;

 etc.

 The information about which classes are statically linked
 is available in the .class file. This information could be
 used (post succesful compile) to modify the source file to
 expand/collapse the list of wildcard imports to the specific
 imports. And also get rid of unused imports.
 
 For example,

 Say, the programmer has the following import statement -

 import java.awt.*;
 import java.util.Vector;

 could be transformed to -

 //*@@*/ import java.awt.*; /* <--- commented out
 import java.awt.Frame;        <--- compiler sees this next time
 import java.awt.Panel;        <--- compiler sees this next time
 //*/
 import java.util.Vector;

 based on the information in .class file.
 (@@ is just an arbitrary pattern to indicate tool modified
 source. it could be any other token)
 (Notice only wild card import was transformed.)

 Further if the user adds some code which requires
 the java.awt.Dialog to be imported they could just delete
 the first slashe like this -

 /*@@*/ import java.awt.*;  /* <--- compiler sees this next time
                               <--- now inside comment
 import java.awt.Frame;        <--- now inside comment
 import java.awt.Panel;        <--- now inside comment
 //*/                          <--- now inside comment
 import java.util.Vector;

 and the cycle starts again. In an IDE like environment
 the compilation error clicking could be hooked up
 to do the fix interactively.

 Such an automated tool could forever put the wild card
 vs specific import controversy to rest.

 I have developed some code which dumps the imports using
 slightly modified version of Chuck McManis's dumClass
 utilities.

 http://www.mcmanis.com/~cmcmanis/java/dump/index.html

 However BCEL http://sourceforge.net/projects/bcel/
 or IBM's Byte Code Toolkit could be used instead.



HTH,
sandip

Sandip V. Chitale                               150, Almaden Blvd
work:  (408) 535 1791 ext: 791          San Jose, CA, USA
email: [EMAIL PROTECTED]                8th floor, Cube 831
web:   http://L064-5440.blazesoft.com

Reply via email to