I've been using CamelHumps in the Ctrl-N and Ctrl-Alt-N popups for as long
as I can remember.
After using the new CamelHumps classname completion for a few minutes, I'm
After using this on a few bigger projects (compiling on JDK 1.5, having 30-40
library dependencies), the plethora of classes on the classpath seems to
diminish the value. The simple fact is that, for any given CamelHumps pattern,
there are at least a couple of matches somewhere in the classpath.
There are a number of reasons for this:
1) Lack of anything between 'package private' and 'public' for class visibility
in Java. A great number of classes in my classpath are public, but should
propably be 'jar/library private'. Not much to be done about this.
2) No ability to exclude JDK implementation classes from classname completion.
Using sun.* classes is bad form, while sometimes there is no other way. However,
excluding JDK implementation classes from classname completion would significantly
reduce the 'CamelHumps classname namespace' pollution. It should be trivial
to implement too, simply filtering on package name pattern. It should be
configurable, and defaulting the the current behaviour off course.
3) No ability to differentiate project libraries in 'primary dependencies'
and 'second-level' or transitive dependencies.
For instance, I have direct dependencies on spring, hibernate and antlr.
Some of these libraries depend on various Jakarta Commons libraries (commons-collections
I wouln't touch any jakarta-commons code with a 10-foot pole. However, some
of my primary dependencies depend on it, so the classnames of the contained
classes are presented in classname completion lists.
Having a per-library setting "Exclude from classname completion" would greatly
improve CamelHumps accuracy.