The Type System - Java: The Good Parts - page 20

tinguish between classes or interfaces that have the same name. It would mean that when you
were implementing a class that has two methods from different interfaces with the same name
and you want to share the implementation, you would need to implement one by making a call
to the other, which creates its own set of headaches. But Java isn't that way, and making the
change now could result in breaking a lot of existing code, so it will probably never be that
way.
This sort of example warrants only a warning because it rarely, if ever, becomes a problem
in actual systems. I don't think that I have ever encountered this problem in the wild. This
does mean that you should try to have descriptive names for your methods when you define
an interface, and should think of other meanings of those method names that could result in
some other interface using the same name (and method signature) for a method with a very
different semantics. Method names such as method1() or doIt() should be avoided, for this
reason and many others. [ 9 ] But if you are building a large system with methods named like
that, then the equivalence of such methods in different interfaces may be low down in your
list of worries.
A Real Problem
Whereas the lack of different namespaces in different interfaces is a potential problem that
hardly ever surfaces, the type system in Java does have one characteristic that will eventually
bite just about everyone doing a large system in the language. And it all started out so simply,
and with such good intentions.
Java was originally the way to provide active content on the World Wide Web. Applets, a par-
ticular kind of Java object that was recognized by browsers, could be sent from one website to
the browser to animate, compute, or otherwise enliven what until then had been static content
from the Web. The reason people were willing to allow such applets into their browser was
that the applets (and Java in general) were billed as secure. The Java language made it difficult
to write badly behaved viruses, the Java security model kept the applets from grabbing local
resources, and the isolation provided by the Java object system kept different applets from in-
terfering with each other. It is hard to remember that Java, now thought of as a heavyweight
enterprise environment, started its life (and gained its original popularity) as a lightweight, se-
cure environment to enliven web pages.
But as Java's popularity was skyrocketing, a security flaw was found. Java allows static
fields in classes, which are shared among all members of the class. This allowed a backdoor
mechanism for applets to communicate with each other. If two applets were members of a