Bug 40654 - compiler produces code incompartible with MS JVM
Summary: compiler produces code incompartible with MS JVM
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 M3   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-23 11:03 EDT by Nick Teryaev CLA
Modified: 2003-08-28 12:14 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Teryaev CLA 2003-07-23 11:03:26 EDT
i'm using eclipse to compile java applet. i have a problem with using 
reflection to create an instance of class. this problem was introduced in 3.0 
M1. 

code snippet is something like:

public Object create(Class type) throws Exception
{
  return type.newInstance();
}

i'm using the method from another place like this: create(SomeClass.class) and 
in some situations this fails with following exception

java.lang.IllegalArgumentException: Unresolved java.lang.Class instance 
(ClassLoader.resolveClass() was not used).
	at java/lang/Class.newInstance (Class.java)
	at ...create (...)  <--- my create(Class) method

"in some situations" means that if SomeClass was loaded before either as a 
result of resolving some other class, or invoking Class.forName
(SomeClass.class.getName()), then exception will not be thrown. i suspect that 
when compiler see SomeClass.class it produce bytecode that loads class but 
didn't resolve it that can be good for performance but bad for ms jvm. Sun's 
plugin does not show this problem.
Comment 1 Philipe Mulet CLA 2003-07-23 17:28:05 EDT
What JDK level is the MS VM at ?
Comment 2 Philipe Mulet CLA 2003-07-23 17:35:35 EDT
The class literal isn't supposed to trigger the load of a class. The bytecode 
sequence we generate uses an array type instead,

X.class => Class.forName("[X").getComponentType();

However this feels like a MS VM bug, since newInstance() is spec'ed saying:
The class is initialized if it has not already been initialized.

You may need to workaround by adding an extra action causing the class to be 
loaded explicitly, or by creating the class forcing it to be loaded:

Instead of using:
X.class => Class.forName("[X").getComponentType();
use: Class.forName("X")

Other compilers are doing the same as we do (jikes, and javac has committed to 
change as well).
Comment 3 Philipe Mulet CLA 2003-07-23 17:35:53 EDT
Ok to close?
Comment 4 Nick Teryaev CLA 2003-07-24 02:42:21 EDT
my ms jvm is: Microsoft (R) VM for Java, 5.0 Release 5.0.0.3810
this is 1.1.4 (probably higher) in terms of sun's versions.
Comment 5 Nick Teryaev CLA 2003-07-24 02:56:45 EDT
i compiled the same code with javac and the problem goes away. 

java -version gives following:

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

i agree that it can be just ms jvm bug, but i don't like to change all my code 
from create(A.class) to create(Class.forName(A.class.getName())) because (1) 
there are a lot of places i should do it, (2) Class.forName(A.class.getName()) 
looks ugly.

if you give me some hooks to JDT core code where i can investigate this by 
myself that will okay for me to find it. 
Comment 6 Philipe Mulet CLA 2003-07-24 05:32:21 EDT
Javac hasn't moved yet, though they agreed they should.
Jikes has moved, could you give it a try as well ? (version 1.18 or better).
Comment 7 Philipe Mulet CLA 2003-07-24 05:38:02 EDT
Can't you simply switch to using another VM ?
Comment 8 Nick Teryaev CLA 2003-07-24 05:38:36 EDT
if all are moving to this, and (i suppose) that change fixes something then we 
should close it.
Comment 9 Philipe Mulet CLA 2003-07-24 06:19:36 EDT
Agreed, also see bug 37565 which explains our move, and has a reference to 
javac bug database.
Comment 10 Philipe Mulet CLA 2003-08-28 12:14:14 EDT
Reopening to close as duplicate
Comment 11 Philipe Mulet CLA 2003-08-28 12:14:27 EDT

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