Consider these three class definitions in package core
1 package core;
2
3 enum PLANET {
4 MARS
5 }
6
7 public class A {
8 }
1 package core;
2
3 enum PLANET {
4 VENUS
5 }
6
7 public class B {
8 }
1 package core;
2
3 public class A {
4 public static void main(String... s) {
5 PLANET p = PLANET. //here
6 }
7 }
I appear to have created to default access enums called the same thing
but with different values. In which case I believe them to have the
same fully qualified name (core.PLANET) Im not sure how this is
compiling. It is though and my confusion is compounded by the fact
that the PLANET enum used by the //here comment resolves to the enum
in class A. Why does it choose that one?
TIA
Richard
Lew - 20 Nov 2007 14:22 GMT
> Consider these three class definitions in package core
>
[quoted text clipped - 30 lines]
> that the PLANET enum used by the //here comment resolves to the enum
> in class A. Why does it choose that one?
I don't know how any of it compiles. Your statement labeled "here" isn't even
legal syntax, never mind how it might resolve the "PLANET" reference. (Class
names are supposed to be in mixed case, first letter upper case, CamelCase
throughout, btw.) You shouldn't be able to define two classes A in the same
package, either.

Signature
Lew
Daniel Dyer - 20 Nov 2007 14:42 GMT
> Consider these three class definitions in package core
>
[quoted text clipped - 30 lines]
> that the PLANET enum used by the //here comment resolves to the enum
> in class A. Why does it choose that one?
How are you compiling these? I haven't tried it but, if you are compiling
them separately, I would imagine that the second enum's class file would
simply over-write the first enum's class file. If you are compiling them
together I would expect a duplicate definition error. Is your last class
supposed to be called A as well? It's a confusing example.
Dan.

Signature
Daniel Dyer
http://www.uncommons.org
richnjones@gmail.com - 20 Nov 2007 17:17 GMT
Sorry if the example was confusing. Let me try and explain
1) The seconds A class was a mistake on my part.
2) I know the //here is not valid where it is. I put //here to show
where I seem to get the oddity.
Thanks Daniel for the pointer to do with compiling classes. I think my
compiled classes had got out of sync. When I cleaned and compiled
again I got the compile error I was expecting. My mistake!
Thanks for looking though
Richard
Roedy Green - 21 Nov 2007 04:00 GMT
>I appear to have created to default access enums called the same thing
>but with different values. In which case I believe them to have the
>same fully qualified name (core.PLANET) Im not sure how this is
>compiling. It is though and my confusion is compounded by the fact
>that the PLANET enum used by the //here comment resolves to the enum
>in class A. Why does it choose that one?
Perhaps the compiler can't tell you have duplicate classes. Whenever
you compile it just replaces the class file with the latest version.
From its point of view, it is not that different from changing the
source file.
To me, the code is just plain nuts and there is no reason to expect it
to work.
You could perhaps find out what is going on by decompiling any class
files that are generated.. See
http://mindprod.com/jgloss/decompiler.html

Signature
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Roedy Green - 21 Nov 2007 11:36 GMT
>Consider these three class definitions in package core
what happens when you compile this mess all at once with javac *.java?

Signature
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com