Community
Participate
Working Groups
We have found a potential class loading issue? However, it seems to have been resolved in Eclipse 2.0 (F2 driver). However, we are looking for a workaround in the current workbench (Eclipse 1.0). This doesn't seem to be a problem with the workbench's JRE since we have built the source and run it successfully with the same JRE outside the workbench. Is this a known problem? Can you provide a workaround for 1.0? Steps to reproduce: ======================= package problem2; public class ClassLoadTest { public static void main(String[] args) { try { Class clz1 = Class.forName("problem2.C"); System.out.println("success"); } catch (Exception e) { System.out.println("error"); e.printStackTrace(); } } } ======================= package problem2; public class C { boolean b = false; private Integer f() { while (true) { try { int x = 3; synchronized (this) { return null; } } finally { if (b) synchronized (this) { int y = 3; } } } } } ======================= Running this in Workbench will give you the following error: java.lang.VerifyError: (class: problem2/C, method: f signature: () Ljava/lang/Integer;) Accessing value from uninitialized localvariable 3 at java.lang.Class.forName1(Native Method) at java.lang.Class.forName(Class.java:134) at problem2.ClassLoadTest.main(ClassLoadTest.java:7) Exception in thread "main"
The following code would work fine: private Integer f() { int x; int y; while (true) { try { x = 3; synchronized (this) { return null; } } finally { if (b) { synchronized (this) { y = 3; } } } } } The problem comes from locals defined in a try/finally when the try block returns. If you extract your locals before the try statement, it will work fine.
Is this good enough for a workaround?
I sent the workaround to the customer. I haven't heard anything back yet, but I'll let you know as soon as I do.
This bug is a duplicate of bug 16279, which got addressed in 2.0 stream. Backporting would be fairly dangerous, since the change in 2.0 stream is quite nasty and relying on other changes.
*** This bug has been marked as a duplicate of 16279 ***
From the customer: Thank you for the workaround, actually we had discovered this as a workaround ourselves as well. However, is their a better workaround, since enclosing variables within a try block achieves data hiding and provides us with better scoping. Furthermore, it is acceptable code since running the code as is with virtually any JRE outside the workbench will work. Do you know of any other workarounds that we may be able to try?
From the customer: What I need to know is, Which compiler..? the JDK given by Hursley..? The javac..? I understand that the development of a fix can be tricky, sensitive and dangerous in some situation maybe this situation might be one but I need to explain to the customer why..? as he is demading a fix, because the workaround is not a good workaround as he has hundread and hundreads of classes to modify to apply the workaround that was suggested (ie. go into every class of his app and take the Fields out of the try{} catch block) Reply: The problem is in the internal compiler that is included in Eclipse, WSWB and WSAD, not an external compiler like Javac. Bad bytecodes are being generated and therefore the class cannot be loaded. The compiler is started from: org.eclipse.pde.internal.core.JDTCompilerAdapter and it's in the org.eclipse.jdt.core plugin. Source is in wswb10\eclipse\plugins\org.eclipse.jdt.core\jdtcoresrc.zip, mostly in the parser and compiler packages. The reason that development says that backporting would be dangerous is that so much code has been changed that relies upon previous changes. Other functionality could be easily broken.
Backporting fix to 1.0 (release into v_146). The fix is quite big, will ensure we pass jck1.3a before calling it good.
Support Note: HD100126.
