In sehr frühen Zeiten der Programmierung mussten Namen von Variablen oder Funktionen mit Bedacht gewählt werden, da sie alle global sichtbar waren. Dann wurden Namensräume, d.h. Namespaces erfunden und später über Objekte und für Java auch Packages weiter verfeinert.
Das Package-System von Java, auch schonmal als “Übel Nummer Eins” bezeichnet, hielt selbst gleichnamige Klassen, beispielsweise java.awt.List und java.util.List, zuverlässig auseinander.
Mit dem Aufkommen von modernen IDEs und deren Fähigkeit zur automatischen Namensergänzung (Code Completion, Content Assist, etc.) werden die Namensräume allerdings wieder klein. Dies merkt man besonders dann, wenn man eine gutgemeinte Bibliothek integriert, die beispielsweise eine eigene Klasse File mitbringt.
Die Lösung wird sein, heuristische Verfahren für die Code Completion einzusetzen, mit Prefixen (JList, etc.) zu arbeiten oder sich wieder deutlich mehr Gedanken über die Namensgebung zu machen. Wir haben das Problem nicht gelöst, sondern nur auf eine neue Ebene gehoben.
Schneide Blog 
Hehe “In sehr frühen Zeiten der Programmiereung …”
Ich hab ein nettes Beispiel für einen Nameskonflikt aus der SW einer namenhaften
Automobilzuliefererfirma. Ist C-Code. Ich stolperte einmal
über Warnings beim Übersetzen der Software, dass einige #defines in
Header-Dateien doppelt definiert sein und überschrieben werden würden.
Da wir prinzipiell versuchen, den Quellcode ohne auftretene
Compiler-Warnings zu schreiben, dachte ich mir, fix ich das, war sowieso in der Nähe am codieren.
Datei 1 sag so aus:
#ifndef _H_ENG
#define _H_ENG
#define get_dsm xyz
#endif
Datei 2 sah so aus und bestand nur aus #defines:
#define get_dsm abc
Aufgerufen wurde es z.B:
#include
#include
Oder aber auch nur:
#include
Oder aber auch nur:
#include
Die C-Dateien haben also unterschiedliche Inhalte der get_dsm-defines bekommen.
Vermutlich wurde ein Teil der SW aus einem anderen Projekt übernommen. Das ganze klappt aber nur, wenn in jeder include-Kette die Reihenfolge die richtige ist und wenn Datei2 auch sicher immer eingelesen wird (deshalb kein #ifndef in Datei 2, könnte eventuell ja schon vorher eingelesen worden sein …). Das nette war, dass wenn man die Anweisung #include rausschmiss, der Code trotzdem übersetzte, wir eine Warning weniger hatten, die Software allerdings an der Stelle nicht mehr das tat, was sie sollte.
Ich hab dann alles so gelassen wie es ist.
Du kannst irgendwo in den Preferences Namensraeume (Pakete) aus der Autocompletion ausschliessen. Das macht z.B. dann Sinn, wenn Du SWT programmierst und keine AWT-Buttons etc sehen willst.
Abgesehen davon versucht Mylyn, diese Heuristik in deiner Autocompletion zu gestalten. Ist ein fuerchterliches Feature, das die Reihenfolge der Vorschlaege fortlaufend veraendert. Kann man aber auch in den Preferencen ein- oder ausschalten.