Here is a simpler example which also fails.
Here is a simpler example which also fails. Public class Main { public void neverCalled() { A a = new A(); B be = new B(); a. TakeInter(b); } public static void main(String args) { System.out.
Println(".."); } } class A { public void takeInter(A in) { } } class B extends A { } class C { } in the byte code public void neverCalled(); Code: 0: new #2 // class A 3: dup 4: invokespecial #3 // Method A. "":()V 7: astore_1 8: new #4 // class B 11: dup 12: invokespecial #5 // Method B. "":()V 15: astore_2 16: aload_1 17: aload_2 18: invokevirtual #6 // Method A.
TakeInter:(LA;)V 21: return The be is implicitly cast to an A and it appears to need to check this. If you turn all verification off, no error occurs. $ rm A.
Class B. Class C. Class $ java -Xverify:none -cp .
Main .. $ java -cp . Main Exception in thread "main" java.lang. NoClassDefFoundError: A.
Peter, thanks for the clarification. However, I still don't understand why it is throwing the error before the code is used. It seems to conflict the VM spec.
– Eric Rosenberg Nov 18 at 17:05 When it loads the class it verifies the byte code, unless you try byte code verification off. You could log it as a bug, as it appears to be an edge case that hasn't been considered. – Peter Lawrey Nov 19 at 11:54.
Your quote from Section 2.17.1 was massively out of context. It's in bold below. When read in context, it's clear that "errors...must be thrown at a point in the program..." means "errors...must be thrown by the time the program reaches a point...".
The sentence, by itself, could be worded better - but it's not by itself. The resolution step is optional at the time of initial linkage. An implementation may resolve a symbolic reference from a class or interface that is being linked very early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively.(This resolution may result in errors from further loading and linking steps.) This implementation choice represents one extreme and is similar to the kind of static linkage that has been done for many years in simple implementations of the C language.
An implementation may instead choose to resolve a symbolic reference only when it is actually used; consistent use of this strategy for all symbolic references would represent the "laziest" form of resolution. In this case, if Terminator had several symbolic references to another class, the references might be resolved one at a time or perhaps not at all, if these references were never used during execution of the program. The only requirement regarding when resolution is performed is that any errors detected during resolution must be thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error.
In the "static" example implementation choice described earlier, loading and linking errors could occur before the program is executed if they involved a class or interface mentioned in the class Terminator or any of the further, recursively referenced classes and interfaces. In a system that implemented the "laziest" resolution, these errors would be thrown only when a symbolic reference was used. The two subsequent sentences make the meaning very clear.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.