Bug 42841 - Eclipse generates different order of static initializers than javac
Summary: Eclipse generates different order of static initializers than javac
Status: RESOLVED DUPLICATE of bug 37565
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.0 M4   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-09 18:16 EDT by Stefan Matthias Aust CLA
Modified: 2003-09-10 08:40 EDT (History)
0 users

See Also:


Attachments
InitializerBug.java (590 bytes, text/plain)
2003-09-09 18:18 EDT, Stefan Matthias Aust CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Matthias Aust CLA 2003-09-09 18:16:35 EDT
I'm not sure whether this is a bug of Eclipse or javac.  However, I found that
javac 1.4.2_01 and Eclipse 3.0M3 compile the attached code differently and one
compiler should be wrong (or the Java language spec is ambiguous).  I'd say
Eclipse is right but just to make sure, I created this bug.

When compiled with javac, the code emits "null", when compiled with Eclipse, the
code emits a DataFlavor instance.  Please notice the somewhat recursive
initialization sequence.
Comment 1 Stefan Matthias Aust CLA 2003-09-09 18:18:06 EDT
Created attachment 6059 [details]
InitializerBug.java
Comment 2 Stefan Matthias Aust CLA 2003-09-09 18:20:49 EDT
I forgot, I'm using the default 1.3 Compiler compliance level with default 1.1
.class file compatibility.  I used no -source or -target options on javac.
Comment 3 Olivier Thomann CLA 2003-09-10 08:40:41 EDT
This is another example of bug 37565. Sun compiler initializes the class when
the class literal is used.
In your example, B.class initializes the class B, but at this moment f is not
initialized yet.
Eclipse compiler follows the JLS and doesn't initialize the class B when B.class
is called. Then B will be initialized when B.fs[0] is called and at this moment,
f is initialized in the class InitializerBug.
Close as duplicate of bug 37565.

*** This bug has been marked as a duplicate of 37565 ***