Bug 47291 - java.lang.VerifyError on Ant compiled class
Summary: java.lang.VerifyError on Ant compiled class
Status: RESOLVED WORKSFORME
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 M6   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-22 09:22 EST by Boris Pruessmann CLA
Modified: 2003-12-03 10:51 EST (History)
0 users

See Also:


Attachments
Archive containing class files that resulted from Ant build (18.70 KB, application/zip)
2003-11-22 09:24 EST, Boris Pruessmann CLA
no flags Details
Archive containing class files that resulted from Eclipse internal build (18.53 KB, application/zip)
2003-11-22 09:25 EST, Boris Pruessmann CLA
no flags Details
Offending Source (23.97 KB, application/octet-stream)
2003-11-23 05:16 EST, Boris Pruessmann CLA
no flags Details
The build.xml (6.88 KB, text/xml)
2003-11-24 09:14 EST, Boris Pruessmann CLA
no flags Details
Build Log (59.46 KB, text/rtf)
2003-11-25 03:34 EST, Boris Pruessmann CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Boris Pruessmann CLA 2003-11-22 09:22:30 EST
Eclipse 3.0 M5

Having compiled several plugins by running the PDE created build.xml, I am encountering the 
following problem trying to use that code:

java.lang.VerifyError: (class: net/sourceforge/perforce/ui/views/
PendingChangeListView$ContentProvider, method: hasChildren signature: (Ljava/lang/Object;)Z) 
Illegal use of nonvirtual function call)

Assuming that Eclipse Ant still uses the Eclipse compiler I am entering this as bug in JDT core.
Comment 1 Boris Pruessmann CLA 2003-11-22 09:24:58 EST
Created attachment 6916 [details]
Archive containing class files that resulted from Ant build
Comment 2 Boris Pruessmann CLA 2003-11-22 09:25:42 EST
Created attachment 6917 [details]
Archive containing class files that resulted from Eclipse internal build
Comment 3 Philipe Mulet CLA 2003-11-22 10:56:29 EST
Did it work better with internal built files ? 

Can you attach the sources which correspond to the offending files ?
Comment 4 Boris Pruessmann CLA 2003-11-22 11:36:09 EST
yes it worked better with files built internally (see second attachment). The sources for that specific 
class will not compile standalone, so I would have to provide the whole sources. Do you still want 
them?
Comment 5 Philipe Mulet CLA 2003-11-22 15:43:08 EST
Only the source of the offending .class file. Can you narrow down the offending 
pattern ? This likely is an expression or statement which is misgenerated, and 
doesn't require other files (if cutting dependencies).

But definitely, the offending source is needed.
Comment 6 Boris Pruessmann CLA 2003-11-23 05:16:38 EST
Created attachment 6918 [details]
Offending Source

Disassembling PendingChangelistView$ContentProvider (the offending class)
showed that the incorrect version has translated the super.* calls to
BaseWorkbenchContentProvider.* calls while the correct version compiled them to
WorkbenchContentProvider.* calls.
Comment 7 Philipe Mulet CLA 2003-11-23 07:09:42 EST
Which setting did you use when using the Ant task ? Which JRE is it running on ?
Did you use the Eclipse Ant compiler task ?
Also, what are the settings you use for your Eclipse project (internal) ?

Comment 8 Boris Pruessmann CLA 2003-11-23 12:06:44 EST
> Which setting did you use when using the Ant task ? 

Defaults. Didn't change anything.

> Which JRE is it running on ?

1.4.2_01

> Did you use the Eclipse Ant compiler task ?

If it's still the default - yes.

> Also, what are the settings you use for your Eclipse project (internal) ?

Again, defaults.

I just installed Eclipse 3.0 M5, used a fresh workspace. Checked out some sources via CVS from 
SourceForge (p4eclipse project). Created the build.xml from the plugin.xml and compiled with the 
resulting build.xml. Nothing else was touched.
Comment 9 Philipe Mulet CLA 2003-11-24 06:56:07 EST
Did you set the following property in the Ant javac task you invoked ?

<property 
  name="build.compiler" 
  value="org.eclipse.jdt.core.JDTCompilerAdapter"/>

If not, then you aren't using the Eclipse compiler.
Comment 10 Boris Pruessmann CLA 2003-11-24 07:38:51 EST
It looks like the PDE-generated build.xml does this (at least it did on M4). So, JDTCompilerAdapter 
is used.
Comment 11 Philipe Mulet CLA 2003-11-24 08:02:25 EST
Can you attach the generated build xml file ?
Comment 12 Boris Pruessmann CLA 2003-11-24 09:14:33 EST
Created attachment 6929 [details]
The build.xml

BTW: I have the problem on Windows and on MacOS ...
Comment 13 Olivier Thomann CLA 2003-11-24 13:37:58 EST
Could you please check if the build.xml runs in the same VM as Eclipse or a
separate VM?
You can find this information here:
1) Open the external tools launch that is launching your build.xml.
2) Go to the JRE tab.
See if the runtime JRE is set to:
Run in same JRE as the workspace or
Alternate JRE.

Thanks. I will try to investigate once I have this information.
Comment 14 Olivier Thomann CLA 2003-11-24 14:30:38 EST
Could you please also provide the console contents when you run your build.xml file?
Attach it to this PR.
Thanks.
Comment 15 Boris Pruessmann CLA 2003-11-25 03:34:20 EST
Created attachment 6944 [details]
Build Log

JRE is set to same as workspace.
Comment 16 Olivier Thomann CLA 2003-11-25 10:13:14 EST
Can you try to change your build.xml replacing:

	<property name="javacSource" value="1.3"/>
	<property name="javacTarget" value="1.1"/>

with:

	<property name="javacSource" value="1.3"/>
	<property name="javacTarget" value="1.2"/>

And let me know if this is fixing your problem?

Thanks.
Comment 17 Olivier Thomann CLA 2003-11-25 11:35:04 EST
I would need the whole test case to test it myself.
Comment 18 Boris Pruessmann CLA 2003-11-25 14:29:13 EST
Changing javacTarget makes no difference.
Comment 19 Boris Pruessmann CLA 2003-11-25 14:39:45 EST
Looks like this only happens when compiling against M5 plugins but running the result with a 
previous (e.g. M4) Eclipse build. Let me know if this issue is still of interest for you and I'll send you 
the projects.
Comment 20 Olivier Thomann CLA 2003-11-25 14:41:51 EST
Then could you please tell me where to get the whole project? I need to 
investigate compiling all the classes.
Thanks.
Comment 21 Olivier Thomann CLA 2003-11-25 14:44:27 EST
Ok, this could be related to the RCP changes between M4 and M5.
Is it running ok with M5 plugins? If yes, then this is due to the massive 
refactoring in eclipse ui code.
Comment 22 Boris Pruessmann CLA 2003-11-25 15:55:03 EST
It is running with M5. But it's also running with M4 if I don't compile with Ant. For me it's okay 
since I won't be targeting 3.0 versions < M5 for long but it might be a problem anyway.

The sources are available via CVS: :pserver:anonymous@cvs.sourceforge.net:/cvsroot/p4eclipse

You'll need net.sourceforge.perforce.api, net.sourceforge.perforce.api.win32, 
net.sourceforge.perforce.core and net.sourceforge.perforce.ui (which is the plugin with the 
problem)
Comment 23 Olivier Thomann CLA 2003-11-25 16:07:54 EST
When you say "it is running with M4", are you sure that you are compiling 
against M5 plugins inside Eclipse. I would not be surprise if your self-hosting 
workspace contains M4 plugins.
If you compile against M4 plugins, you have to run it with M4 plugins. If you 
compile with M5 plugins, you have to run it with M5 plugins.
Are you sure this is what you are doing inside Eclipse? It should not make any 
difference between what has been compiled inside Eclipse or with Ant using 
Eclipse compiler as long as you are compiling using the same plugins on the 
classpath.
Could you please attach your .classpath file for the ui project?

I cannot connect to the cvs server. Could be a firewall issue. I will request 
access to it.
Comment 24 Boris Pruessmann CLA 2003-11-26 02:36:27 EST
That's a good point. I am quite sure that my workspace contains the M5 plugins but I'll verify that. 
Nevertheless, I am doing internal build and ant build from the same workspace, doesn't that mean 
that in both situations I compile against the same plugins? Or does the ant build work against the 
hosting Eclipse version?

(I'll try to send the .classpath or even the projects later)
Comment 25 Olivier Thomann CLA 2003-12-01 13:18:45 EST
You problem could be a PDE issue. The plugins used to compile the code are not
the one you think.
From the compiler point of view, if running on M5 works fine when compiled with
M5 plugins and running on M4 works fine when compiled with M4 plugins, then it
is ok and we can close this PR.
Compiling with M4 plugins and running on M5 can fail due to major reorg in ui
plugins.
Comment 26 Olivier Thomann CLA 2003-12-03 10:51:26 EST
Close as WORKSFORME.
Please reopen if you still believe this is a compiler issue.