Eclipse & classpath magic

[Mark Space]

Hey all.

I decided to learn a new IDE so I'm poking at Eclipse. I've too small
projects now, and just noticed something odd. Both projects have their
own name and live in the workspace directory. Just without thinking, I
put all classes in both projects in the package "local." The resulting
directory structure looks something like this:

..../workspace/Project1/local/[*.class][*.java]
..../workspace/Project2/local/[*.class][*.java]

Yes, both projects are quickies with a single class, so Project1/local/
has Semaphore.class and Semaphore.java, and Project2 has
CircularByteBuffer.class and CircularByteBuffer.java.

So here's my question: CircularByteBuffer uses the Semaphore class.
Since they're in the same package, I didn't have to use an import
statement, which confused me a bit because the two packages are in
different directory hierarchies.

So is this normal? I.e., a normal use of the default Java classloader?

I've never run into this situation before, where the same package is
stored in multiple directory hierarchies. It seems almost like a
security hole (because I could add, or replace classes in any package
just by adding a new directory to the classpath) but that's not my main
point.

I assume that Eclipse has added ".../workspace/Project1/" and
".../workspace/Project2/" to the classpath. Is that correct? And the
classloading is just normal JVM behavior? If there's any Eclipse magic
going on behind the scenes, I'm interested to know what it is.

Ok, excuse my noobishness. Thanks in advance!

 

[a24900]

So here's my question: CircularByteBuffer uses the Semaphore class.
Since they're in the same package, I didn't have to use an import
statement, which confused me a bit because the two packages are in
different directory hierarchies.

So is this normal? I.e., a normal use of the default Java classloader?

Perfectly normal. Packages are open-ended. Next time some of these
"how can I get a list of all classes in a package, I am sure it must
be possible" whiners come to this group, you can give them the right
answer, one can't.

I've never run into this situation before, where the same package is
stored in multiple directory hierarchies.

Read up on how the classpath works.

It seems almost like a
security hole (because I could add, or replace classes in any package
just by adding a new directory to the classpath)

It is your user environment. If someone can change your classpath,
adding a new directory and adding class files, then that someone can
as well place new binaries in your directory, replace existing
binaries and change configurations of your account. So a new class is
the least you have to worry about in that situation.

 

[Mark Space]

Read up on how the classpath works.

I know the basics, I think. I've just been copying all my .class files
to a single directory hierarchy so I've avoided this behavior until now.
It's convenient to do it this way (one hierarchy) because I can
control when .class files get "deployed" locally and I don't have to be
constantly editing the system classpath.

Thanks for the info though. It's funny the assumptions people sometimes
make, I guess.