Re: is package a namespace?
On Jul 24, 5:48 pm, Lew <l...@lewscanon.com> wrote:
Eric Sosman wrote:
I don't know C++ and can't say whether Java is "like" it,
nor whether Java shares the same problems. If you're worried
that a custom ClassLoader could substitute its own String or
JButton for those provided with Java, the answer is No: You
can load a new java.lang.String or javax.swing.JButton class,
but they won't be the same classes as those Java provides, nor
will they be in the same packages.
One should note that naming a top-level package 'java' or 'javax' is a
trademark violation and a Bad Thing generally. Not that that is a
deterrent to malicious programmers.
More to the point, the JVM will not load classes whose packages begin
with java. or javax. except from the bootstrap classloader, as I
understand it; the intent is to prevent malicious or merely dimwitted
programmers from replacing java.lang.String without demonstrating that
they own the JVM (by being able to manipulate that particular
classloader) first.
To the OP, yes, packages are roughly analogous to C++ namespaces,
except for two fundamental differences:
1. They don't nest; the package "foo.bar" is not inside the package
"foo".
2. They can only contain classes, not free functions or namespace-
scoped variables.
By themselves, packages and package-level visibility are no more
protection from malicious code than any other visibility feature;
however, the Java runtime takes JAR signing and sealing[0] into
account when loading classes in a sandboxed environment, which can be
used (carefully) to isolate libraries from each other forcibly.
-o
[0] described at <http://java.sun.com/javase/6/docs/technotes/guides/
jar/jar.html>