Hi, I am using an empty interface to indicate that a certain operation (filtering) is possible on objects implementing it (much like the way Cloneable works). The jde-wiz-implement-interface wizard doesn't support this perfectly, since it adds 'implements Filterable' but doesn't generate an import statement. It seems to be a problem in jde.wiz.InterfaceFactory.process():
public void process(String name, boolean truncate) throws ClassNotFoundException, NotAnInterfaceException { if (null == namefactory) namefactory = new DefaultNameFactory(); Class aclass = Class.forName( name ); if (false == aclass.isInterface()) throw new NotAnInterfaceException(name); registerImport(aclass); // <------------------------------- Added by Petter Method[] methods = aclass.getMethods(); for (int i = 0; i < methods.length; i++) sortByDeclaringClass( new Signature( methods[i], this, truncate ) ); } Without the flagged line, if there are no methods in the interface, the interface class will not be imported. However, when I had found this, I also found a second problem, which I cannot quite understand. I used a test class like this: ============== public class IFTest { } // IFTest ============== And a test interface (in a different package) like this: ============== package dbgtest; public interface IF { }// IF ============== When I have the IFTest.java buffer open and do a jde-wiz-implement-interface and specify IF, the import statement is correctly generated. However, I normally have jde-import-auto-collapse-imports set to true, which means that the import statement is immediately deleted! (the *Messages* buffer indicates that an import is removed) In my "real" class, that doesn't happen. I don't understand why, and I cannot quite understand the jde-import-kill-extra-imports function, which I guess is the culprit. Additionally, if I call jde-import-kill-extra-imports with the following file, the import statement is correctly left in place: ============== import dbgtest.IF; public class IFTest implements IF { } // IFTest ============== I guess it might be something in the interplay between semantic and JDE that is not working under some circumstances. In any case, I believe that the first fix is correct, and probably the second problem is not too serious. Best regards, Petter