Community
Participate
Working Groups
Build ID: 3.2- Hep, I am getting java.lang.IllegalAccessError: a/A when running b.C for the following files. Using suns javac it works. package a; abstract class A { public final boolean returnTrue() { return true; } } package a; public class B extends A { } package b; import a.B; public class C extends B { public void test1() { // works System.out.println(super.returnTrue()); } public void test2() { // java.lang.IllegalAccessError: a/A // at b/C.test2 // at b/C.main System.out.println(returnTrue()); } public static void main(String[] args) { C c = new C(); // works System.out.println(c.returnTrue()); c.test1(); c.test2(); } } Workaround is to declare class A public, or write super.returnTrue() everywhere. Looking at the bytecode the difference is which class returnTrue() should be found/invoked in. Jview fails when it is class A. Writing super force the bytecode to have class B. I am not familiar enough to the java language to say whether it is a jview bug or eclipse compiler.
What version of javac are you using? Please provide Eclipse compiler settings. Reopen when requested information is available.
C:/Program\ Files/Java/jdk1.5.0_06/bin/javac.exe -source 1.3 -target 1.1 b/C.java Eclipse is setup to the same source and target. Additional are "Add variable attributes..", "Add line number...", "Add source name..", and "Preserve unused ..." turned on.
What is the compliance level for the Eclipse compiler?
The compliance level is set to 1.3
If you compare with javac 1.5, you should set the compliance to be 1.5 and manually set the source to 1.3 and the target to 1.1. This seems to work fine. Closing as INVALID.
Yes, it works for me too. Now, whats the difference between these settings? and were do I read about them? I only found the exact same text in the help file.
(In reply to comment #6) > Yes, it works for me too. > Now, whats the difference between these settings? and were do I read about > them? I only found the exact same text in the help file. What text are you talking about? I'll check the help and I'll try to clarify this point.
>> Now, whats the difference between these settings? > I'll check the help and I'll try to clarify this point. Still in 3.3: * Compiler compliance level - Specifies the compiler compliance level. *Generated class files compatibility - Specifies the generated class file compatibility. *Source compatibility - Specifies the compatibility of the accepted source code. This is not clear to me at all. Please be more elaborate
(In reply to comment #8) > * Compiler compliance level - Specifies the compiler compliance level. This indicates what version of javac it corresponds to. Compliance 1.4 means javac 1.4. > *Generated class files compatibility - Specifies the generated class file > compatibility. This is the target level. This means it corresponds to the VM you are targetting. Target 1.3 to run on a VM 1.3. However you need to use 1.3 libraries on the classpath. > *Source compatibility - Specifies the compatibility of the accepted source > code. This corresponds to the source level that you want the compiler to parse. 1.4 in order to be able to handle the assert statement. 1.5 to be able to handle static imports, new for statements, generics,... > This is not clear to me at all. Please be more elaborate Hope this clarify it a bit
>> * Compiler compliance level - Specifies the compiler compliance level. > This indicates what version of javac it corresponds to. > Compliance 1.4 means javac 1.4. Given say target 1.3 how does this change the classfiles? (with the samme classpath). >> *Generated class files compatibility - Specifies the generated class file >> compatibility. > This is the target level. This means it corresponds to the VM you are > targetting. Target 1.3 to run on a VM 1.3. However you need to use 1.3 > libraries on the classpath. So if I dont change the classpath this will change nothing? Or is this the languange specification setting? Say target was 1.1, but I had 1.5 in classpath, then calls to stringbuffer.append(stringbuffer) is still generated? >> *Source compatibility - Specifies the compatibility of the accepted source >> code. > This corresponds to the source level that you want the compiler to parse. 1.4 > in order to be able to handle the assert statement. 1.5 to be able to handle > static imports, new for statements, generics,... Is it correct if I say that this does not change the output classes (if it compiles)? Hmm, I am not sure why this is under compiler, as this is something I want my editor to tell me (e.i mark the "errors").
The compliance level set to 1.3 means that the target level is 1.1. This affects some method invocation resolution. The declaring class is set differently. This is exactly what is causing you grief. If you use javac 1.3 you should end up with the same issue.
Hmm, you didnt answered all 3 questions. So here is a 4th: > The compliance level set to 1.3 means that the target level is 1.1. Are you implying that if I set target manually then compliance level is ignored?
(In reply to comment #12) > Hmm, you didnt answered all 3 questions. So here is a 4th: I don't know exactly what kind of answers you expect. > The compliance level set to 1.3 means that the target level is 1.1. > Are you implying that if I set target manually then > compliance level is ignored? The compliance level is not ignored, but you can change the default target level. Each compliance level comes with a default source and target level. These default values can be overriden. Your problem is that you are not comparing the same thing. In comment 2, you show a command line that you use to run javac. If you don't set the compliance level to 1.5 and the target to 1.1 and the source to 1.3, you cannot compare our results with what javac produces according to comment 2. What do you expect? I reopen this bug?
