Bug 39839 - Compiler optimization breaks user code
Summary: Compiler optimization breaks user code
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: 3.0 M2   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-09 17:16 EDT by David Whiteman CLA
Modified: 2003-07-10 07:12 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Whiteman CLA 2003-07-09 17:16:21 EDT
I have had code for a long time that, in a static initalizer, "touches" another 
class so that its static initializer will run.  Here is an example:

public class Foo {
  static {
    Bar.class.getName();
  }
  public Foo() {
  }
  public static void main(String[] args) {
     new Foo();
  }
}

public class Bar {
  static {
    System.out.println("in bar");
  }
}

In Eclipse 2.1, running main() on Foo would have resulted in the statement "in 
bar" printing.  It appears that in the M1 build, the Bar.class.getName() has 
been optimized such that the Bar static initializer doesn't get run.  This has 
broken my code since I was relying on this behavior.  Is there some other way 
via reflection to force Bar's initialization?
Comment 1 Philipe Mulet CLA 2003-07-10 07:12:00 EDT
Actually, our old behavior was wrong (see bug 37565). The class literal should 
not force to load the target class.

Using a straight Class.forName("Bar") will do the trick. What the compiler 
instead performs is: Class.forName("[LBar;").getComponentType() so as to avoid 
initializing the class (Jikes and future Javac will presumably do it so).