The conflicting names really shouldn't be a problem as long as you're creating logically separated entities (different classes). This is where modelling comes in to play, just as it does in any well-designed system.
Java is a very well-designed system in that it is completely designed for code re-use, which means there should never be a need for conflicting names because everything should be logically separated, or else extending something previously written (which would also make it separate). This lends itself real easily to long and ambiguous classnames, which I know a few of for example because at work everyone simply adds a new
word to the class they build from, sometimes classes are 5-10 words in length, getting in between 15 and 30 characters. I agree with you that sometimes the conflicting namespace would be hard to avoid, and there really should be some standard set as to when you need to define a separate package for one type of class, as opposed to separate classes in a package where a lot of different types of Objects exist.
For example, lets say that there's 10 different types of Apples in the FruitStand package. There could be GalaApples, MacintoshApples, GrannySmithApples, RedDeliciousApples, etc., mixing around with your other classes like your Oranges, Bananas and whatnot. At what point do you try to avoid the confusion and make a separate subpackage called FruitStand.Apples.*?
I don't know what Sun has to say on the above example, but I'm sure the people modeling might have different ways they prefer to do it. All I know, is that as long as you know the way that your packages are defined, and keep things separated by function, the naming conflicts can be kept miniscule.
I don't know if what I said at all makes sense to anyone else, or even answered the question for that matter, but I think it could be the grounds for a good discussion.
In Java,
Larry
