Is the following legal?

B

bluke

I have the following:
package test1;

class Test {
public final Color RED = new Color("red");

protected static final class Color {
private String id;
private Color (String id) {
this.id = id;
}
public String toString() {
return id;
}
}
}

package test1;
public class Test1 extends Test {
}

package test2;
public class Test2 extends Test1 {
someMethod(RED);
}


I am getting an IllegalAccessError with this because Class Test is
package protected and Test2 is in a different package, so when Test2
tries to access RED I get an IllegalAccessError that tried to access
class test1.Test from class test2.Test2. The interesting thing about
this is that it compiles. This means that there is either a VM bug or
a compiler bug, because if it compiles I should not get an
IllegalAccessError. Is this actually legal?
 
K

kaeli

I am getting an IllegalAccessError with this because Class Test is
package protected and Test2 is in a different package, so when Test2
tries to access RED I get an IllegalAccessError that tried to access
class test1.Test from class test2.Test2. The interesting thing about
this is that it compiles. This means that there is either a VM bug or
a compiler bug, because if it compiles I should not get an
IllegalAccessError. Is this actually legal?

This is a runtime error, not a compile time error, so no, the compiler
won't catch it.
It is not allowed (illegal) to do what you're trying to do.

--
 
J

John C. Bollinger

bluke said:
I have the following:
package test1;

class Test {
public final Color RED = new Color("red");

protected static final class Color {
private String id;
private Color (String id) {
this.id = id;
}
public String toString() {
return id;
}
}
}

package test1;
public class Test1 extends Test {
}

package test2;
public class Test2 extends Test1 {
someMethod(RED);
}


I am getting an IllegalAccessError with this because Class Test is
package protected and Test2 is in a different package,

I'll believe the IllegalAccessError. If you know the cause already,
however then why are you asking here?
so when Test2
tries to access RED I get an IllegalAccessError that tried to access
class test1.Test from class test2.Test2. The interesting thing about
this is that it compiles.

No it doesn't. That is to say, what you gave above is not syntactically
correct Java, and it cannot compile, regardless of any questions of
access control. Moreover, even if it did compile it does not form a
complete Java program so there is no way for you to run it to produce
your error.
This means that there is either a VM bug or
a compiler bug, because if it compiles I should not get an
IllegalAccessError.

That much is correct, in the sense that any situation that produces an
IllegalAccessError should be caught at compile time -- *if the compiler
is allowed to see it*. This sort of problem likely means that you
managed to create a class version mismatch; the version of Test that you
compiled Test1 or Test2 against is different from the version that was
loaded at runtime.
Is this actually legal?

It is not syntactically valid (see above). The access itself could be
legal, however, if the syntax problems were corrected. I generated a
valid program based on your example and without changing any access
modifiers; it compiled and ran fine. If you have further questions then
please post an actual code with which your problem can be reproduced.


John Bollinger
(e-mail address removed)
 
B

bluke

I only posted snippets of code to illustrate the problem, of course
the posted posted doesn't actually compile. I didn't think that I
needed to post complete Java code to illustrate the problem.

I cannot see how I crteated a class version mismatch, I conpiled the
code and then ran it all within the same IDE.
 
B

bluke

kaeli said:
This is a runtime error, not a compile time error, so no, the compiler
won't catch it.
It is not allowed (illegal) to do what you're trying to do.
It should be a compile time error. The documentation for IllegalAccessError states:
" Normally, this error is caught by the compiler; this error can
only occur at run time if the definition of a class has
incompatibly changed. "
In this case the definition of teh class has not changed.
 
J

John C. Bollinger

Please don't top post.
I only posted snippets of code to illustrate the problem, of course
the posted posted doesn't actually compile. I didn't think that I
needed to post complete Java code to illustrate the problem.

If you cannot identify a specific problem in your code, then you don't
really know where the trouble is. In that case, you risk leaving out
relevant parts when you post only excerpts, and indeed, in my experience
leaving out important bits is the rule rather than the exception in such
situations. Sometimes the work of producing a minimal example to
demonstrate the problem is enough to help you discover it for yourself.
If it isn't, then often that's precisely because the problem is not in
the parts that *you* think are relevant / important.

In your case, I produced a working Java program from your snippets.
That is irrefutable proof that either you did not post enough code to
demonstrate the problem, or the problem isn't in the code itself. I
can't tell you which without seeing a complete example. Furthermore,
you asked about the legality of a Java construct, but did not provide
enough context for anyone to provide a well-considered answer to the
question. The answers to such questions frequently hinge on context and
details, so here again a fuller example is necessary, and a complete
program would be best.
I cannot see how I crteated a class version mismatch, I conpiled the
code and then ran it all within the same IDE.

That does not necessarily protect you. In your example, class Test2
depends on class Test1, which depends on class Test. If you compile
Test, Test1, and Test2, then modify Test and recompile it, Test1 and
Test2 are not necessarily recompiled. Depending on what you did to
Test, classes Test1 and / or Test2 might not need to be recompiled. How
this is handled in a Java IDE varies by IDE. If your IDE has a "rebuild
all" (or equivalent) feature then try using it.


I hope that is enough to help you solve your problem, because I'm done
with you. I don't need to spend any more time being accused of
nitpicking for giving you good advice and valid critique.


John Bollinger
(e-mail address removed)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,477
Members
44,898
Latest member
BlairH7607

Latest Threads

Top