I found there are two classes in JDT with more than 10 KLOC:

codeassist/org/eclipse/jdt/internal/codeassist/CompletionEngine.java

compiler/org/eclipse/jdt/internal/compiler/parser/Parser.java

I found there are two classes in JDT with more than 10 KLOC:

codeassist/org/eclipse/jdt/internal/codeassist/CompletionEngine.java

compiler/org/eclipse/jdt/internal/compiler/parser/Parser.java

private int computeRelevanceForAnnotation()
private int computeRelevanceForAnnotationTarget(TypeBinding typeBinding)
private int computeRelevanceForClass()
private int computeRelevanceForEnum()
private int computeRelevanceForEnumConstant(TypeBinding proposalType)

Zhongpeng Lin wrote on Thu, 12 April 2012 20:10

I found there are two classes in JDT with more than 10 KLOC:

codeassist/org/eclipse/jdt/internal/codeassist/CompletionEngine.java

This class indeed causes some pain every now and then. For regular JDT/Core development it is manageable, but I also maintain a fork of the JDT/Core (for Object Teams) and there merging changes into this class did cause significant grief in the past.

I shyly suggested refactoring that class, which stalled probably because also an appropriate refactoring would be quite a challenge at this point. It would have been easier to split this way earlier in the development, I guess.

Quote:

compiler/org/eclipse/jdt/internal/compiler/parser/Parser.java

For this class the huge size is quite natural: a long method (consumeRule) is generated by the parser generator (jikespg) and all methods called from there must be found in the same class. Size isn't causing much harm here, since methods are quite uniform, so complexity isn't too high, actually.

HTH,
Stephan

Thanks Stephan for the reply.

Looking into the method lists for both classes as an outsider, I found many methods in each class share common prefixes, which are all verbs; they are only different in the object they process. Example in org.eclipse.jdt.internal.codeassist.CompletionEngine:

private int computeRelevanceForAnnotation()
private int computeRelevanceForAnnotationTarget(TypeBinding typeBinding)
private int computeRelevanceForClass()
private int computeRelevanceForEnum()
private int computeRelevanceForEnumConstant(TypeBinding proposalType)

Also, the consumeXXX methods in org.eclipse.jdt.internal.compiler.parser.Parser is another example. At the same time, switch statement is used to call different methods based on different object type (e.g. org.eclipse.jdt.internal.compiler.parser.Parser.consumeRule).

These situations seem to show opportunities to take advantage of polymorphism, as suggested by Martin Fowler in his book Refactoring: Improving the Design of Existing Code. By using polymorphism, different processing logic will be encapsulated in different objects/classes, and the size of these two classes will be reduced. This should work at least "in theory",

and I believe developers in JDT are aware of this, but I am interested in what difficulty prevented them from doing such a refactoring.

Any more insights? Thanks again!

Zhongpeng Lin wrote on Thu, 12 April 2012 20:10

I found there are two classes in JDT with more than 10 KLOC:

codeassist/org/eclipse/jdt/internal/codeassist/CompletionEngine.java

This class indeed causes some pain every now and then. For regular JDT/Core development it is manageable, but I also maintain a fork of the JDT/Core (for Object Teams) and there merging changes into this class did cause significant grief in the past.