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