Home » Eclipse Projects » Eclipse Platform » VerifyError with 3.0M3-compiled TextEditor deployed to 2.1
| VerifyError with 3.0M3-compiled TextEditor deployed to 2.1 [message #135612] |
Wed, 24 September 2003 17:57  |
Eclipse User |
|
|
|
Hi all,
When trying to install a new plugin (eTex - Tex Editor by Ian Hartney) from
sourceforge, I got a problem with a strange looking error. I tried to
isolate it, and it seems to have to do with the Eclipse versions I use to
compile (3.0M3) and run (2.1, also tried 2.11 with the same effect).
In a nutshell it's this:
I created, using 3.0M3, a plugin project with just an editor declaration:
<extension
point="org.eclipse.ui.editors">
<editor name="Test-Editor"
icon="icons/myImage.gif"
extensions="my"
class="de.leiffrenzel.test.TestEditor"
id="de.leiffrenzel.test.TestEditor">
</editor>
</extension>
and then implemented TestEditor:
public class TestEditor extends TextEditor {
public void createPartControl( Composite parent ) {
super.createPartControl( parent );
}
}
I packaged the plugin and deployed it to an Eclipse 2.1 version.
When I open the editor now over a "my" file, I get that error (see trace
below).
If I leave out the createPartControl(Composite) overriding, everything works
fine.
Any idea what's going on here?
Ciao,
Leif
===================================================
java.version=1.4.2_01
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Command-line arguments: -os win32 -ws win32 -arch x86 -install
file:C:/testspace/temp/eclipse/
java.lang.VerifyError: (class: de/leiffrenzel/test/TestEditor, method:
createPartControl signature: (Lorg/eclipse/swt/widgets/Composite;)V) Illegal
use of nonvirtual function call
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:16 10)
at java.lang.Class.getConstructor0(Class.java:1922)
at java.lang.Class.newInstance0(Class.java:278)
at java.lang.Class.newInstance(Class.java:261)
at
org.eclipse.core.internal.plugins.PluginDescriptor.createExe cutableExtension
(PluginDescriptor.java:138)
at
org.eclipse.core.internal.plugins.PluginDescriptor.createExe cutableExtension
(PluginDescriptor.java:167)
at
org.eclipse.core.internal.plugins.ConfigurationElement.creat eExecutableExten
sion(ConfigurationElement.java:103)
at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugi n.java:158)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:69)
at
org.eclipse.ui.internal.WorkbenchPlugin.createExtension(Work benchPlugin.java
:155)
at org.eclipse.ui.internal.EditorManager$3.run(EditorManager.ja va:676)
at
org.eclipse.core.internal.runtime.InternalPlatform.run(Inter nalPlatform.java
:889)
at org.eclipse.core.runtime.Platform.run(Platform.java:413)
at org.eclipse.ui.internal.EditorManager.createPart(EditorManag er.java:674)
at
org.eclipse.ui.internal.EditorManager.openInternalEditor(Edi torManager.java:
661)
at
org.eclipse.ui.internal.EditorManager.openEditorFromDescript or(EditorManager
..java:459)
at org.eclipse.ui.internal.EditorManager.openEditor(EditorManag er.java:431)
at
org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(Workben chPage.java:2054
)
at org.eclipse.ui.internal.WorkbenchPage.access$6(WorkbenchPage .java:2004)
at org.eclipse.ui.internal.WorkbenchPage$9.run(WorkbenchPage.ja va:1991)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:69)
at
org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:1986)
at
org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:1879)
at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu. java:237)
at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.ja va:231)
at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMe nu.java:155)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :81)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:840)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:1838)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :1545)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1402)
at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385)
at
org.eclipse.core.internal.boot.InternalBootLoader.run(Intern alBootLoader.jav
a:845)
at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl
..java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.eclipse.core.launcher.Main.basicRun(Main.java:291)
at org.eclipse.core.launcher.Main.run(Main.java:747)
at org.eclipse.core.launcher.Main.main(Main.java:583)
|
|
|
| Re: VerifyError with 3.0M3-compiled TextEditor deployed to 2.1 [message #135688 is a reply to message #135612] |
Wed, 24 September 2003 21:49  |
| Eclipse User |
|
|
|
You cannot develop on version 3.0 and run on 2.1.
Your code was compiled against classes with different implementations.
Load your plugin in 2.1, rebuild it, package it, and it should run better.
2.x and 3.x are not ensured binary compatble. Some API will change.
Chris
"Leif Frenzel" <himself@leiffrenzel.de> wrote in message
news:bkt3sl$lpk$1@eclipse.org...
> Hi all,
>
> When trying to install a new plugin (eTex - Tex Editor by Ian Hartney)
from
> sourceforge, I got a problem with a strange looking error. I tried to
> isolate it, and it seems to have to do with the Eclipse versions I use to
> compile (3.0M3) and run (2.1, also tried 2.11 with the same effect).
>
> In a nutshell it's this:
>
> I created, using 3.0M3, a plugin project with just an editor declaration:
>
> <extension
> point="org.eclipse.ui.editors">
> <editor name="Test-Editor"
> icon="icons/myImage.gif"
> extensions="my"
> class="de.leiffrenzel.test.TestEditor"
> id="de.leiffrenzel.test.TestEditor">
> </editor>
> </extension>
>
> and then implemented TestEditor:
>
> public class TestEditor extends TextEditor {
> public void createPartControl( Composite parent ) {
> super.createPartControl( parent );
> }
> }
>
> I packaged the plugin and deployed it to an Eclipse 2.1 version.
>
> When I open the editor now over a "my" file, I get that error (see trace
> below).
>
> If I leave out the createPartControl(Composite) overriding, everything
works
> fine.
>
> Any idea what's going on here?
>
> Ciao,
> Leif
>
> ===================================================
>
> java.version=1.4.2_01
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
> Command-line arguments: -os win32 -ws win32 -arch x86 -install
> file:C:/testspace/temp/eclipse/
>
> java.lang.VerifyError: (class: de/leiffrenzel/test/TestEditor, method:
> createPartControl signature: (Lorg/eclipse/swt/widgets/Composite;)V)
Illegal
> use of nonvirtual function call
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:16 10)
> at java.lang.Class.getConstructor0(Class.java:1922)
> at java.lang.Class.newInstance0(Class.java:278)
> at java.lang.Class.newInstance(Class.java:261)
> at
>
org.eclipse.core.internal.plugins.PluginDescriptor.createExe cutableExtension
> (PluginDescriptor.java:138)
> at
>
org.eclipse.core.internal.plugins.PluginDescriptor.createExe cutableExtension
> (PluginDescriptor.java:167)
> at
>
org.eclipse.core.internal.plugins.ConfigurationElement.creat eExecutableExten
> sion(ConfigurationElement.java:103)
> at
org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugi n.java:158)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:69)
> at
>
org.eclipse.ui.internal.WorkbenchPlugin.createExtension(Work benchPlugin.java
> :155)
> at org.eclipse.ui.internal.EditorManager$3.run(EditorManager.ja va:676)
> at
>
org.eclipse.core.internal.runtime.InternalPlatform.run(Inter nalPlatform.java
> :889)
> at org.eclipse.core.runtime.Platform.run(Platform.java:413)
> at
org.eclipse.ui.internal.EditorManager.createPart(EditorManag er.java:674)
> at
>
org.eclipse.ui.internal.EditorManager.openInternalEditor(Edi torManager.java:
> 661)
> at
>
org.eclipse.ui.internal.EditorManager.openEditorFromDescript or(EditorManager
> .java:459)
> at
org.eclipse.ui.internal.EditorManager.openEditor(EditorManag er.java:431)
> at
>
org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(Workben chPage.java:2054
> )
> at
org.eclipse.ui.internal.WorkbenchPage.access$6(WorkbenchPage .java:2004)
> at org.eclipse.ui.internal.WorkbenchPage$9.run(WorkbenchPage.ja va:1991)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:69)
> at
> org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:1986)
> at
> org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:1879)
> at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu. java:237)
> at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.ja va:231)
> at
org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMe nu.java:155)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :81)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:840)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:1838)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :1545)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1402)
> at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385)
> at
>
org.eclipse.core.internal.boot.InternalBootLoader.run(Intern alBootLoader.jav
> a:845)
> at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39
> )
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl
> .java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:291)
> at org.eclipse.core.launcher.Main.run(Main.java:747)
> at org.eclipse.core.launcher.Main.main(Main.java:583)
>
>
>
>
>
|
|
|
| Binary compatibility / Porting guide [message #135854 is a reply to message #135688] |
Thu, 25 September 2003 08:52 |
| Eclipse User |
|
|
|
Hi Chris,
Thanks for your answer. I read the documents that stated that APIs will
change between 2.x and 3.0 versions. So I see the solution to that
particular problem is to develop or at least compile and deploy from a 2.1
platform. Is there already a draft for that porting guide mentioned in the
Project Plan?
But there is still a more general point I'm not sure about : In the example
I wrote I extend a class that _has_ changed from 2.x to 3.0 with respect to
its superclass set and the precise location of the overriden method. Namely,
the type hierarchy is
2: TextEditor -> StatusTextEditor ...
3: TextEditor -> ExtendedTextEditor -> StatusTextEditor
and the method I override (createPartControl) is implemented in 2 in
StatusTextEditor, but in 3 in ExtendedTextEditor and not in StatusTextEditor
(but it is declared in their common supertype WorkbenchPart in 2 and 3).
This means that with respect to the API referenced in my source file there
has been no change, and I would not have expected the compiler to hardwire
the call to super.createPartControl() as directed to StatusTextEditor. But
this is what the Eclipse compiler apparently does. I compared it with a
similar scenario compiled with the Sun javac, which didn't.
If I understand this correctly, then there is a difference in the behaviour
of the Eclipse compiler and Sun javac, which results in this case in a more
specific reference in the bytecode created by the former. And in situations
like in my example, this has consequences for binary compatibility, which
wouldn't necessarily be there with the compile strategy of the latter. (I
presume that it may have its advantages too, maybe in respect to performance
or sth. like that.)
Is there some document or discussion in respect to that behaviour of the
compiler somewhere? Possibly stating the reasons for implementing it that
way, and discussing the relations to the binary compatibility rules in the
JLS?
Thx again & ciao,
Leif
"Chris Laffra" <Chris_Laffra@oti.com> schrieb im Newsbeitrag
news:bkthge$9s$1@eclipse.org...
> You cannot develop on version 3.0 and run on 2.1.
> Your code was compiled against classes with different implementations.
> Load your plugin in 2.1, rebuild it, package it, and it should run better.
>
> 2.x and 3.x are not ensured binary compatble. Some API will change.
>
> Chris
|
|
|
| Re: Binary compatibility / Porting guide [message #136025 is a reply to message #135854] |
Thu, 25 September 2003 13:03 |
| Eclipse User |
|
|
|
This is Java spec behavior, exactly as the language dictates it.
I actually confirmed it for you:
$
$
$
$ cat A.java
public class A { public void foo() { } }
$ cat B.java
public class B extends A { public void foo() { super.foo(); } }
$ javac A.java B.java
$ cfdump -b B.class
public class B extends A
{
public void <init>();
public void foo();
}
public void <init>()
0 JBaload0
1 JBinvokespecial 1 A.<init>()V
4 JBreturn
public void foo()
0 JBaload0
1 JBinvokespecial 2 A.foo()V <----- calls A.foo
4 JBreturn
$
$
$
Chris
"Leif Frenzel" <lfrenzel@innoopract.de> wrote in message
news:bkuo6r$19p$1@eclipse.org...
> Hi Chris,
>
> Thanks for your answer. I read the documents that stated that APIs will
> change between 2.x and 3.0 versions. So I see the solution to that
> particular problem is to develop or at least compile and deploy from a 2.1
> platform. Is there already a draft for that porting guide mentioned in the
> Project Plan?
>
> But there is still a more general point I'm not sure about : In the
example
> I wrote I extend a class that _has_ changed from 2.x to 3.0 with respect
to
> its superclass set and the precise location of the overriden method.
Namely,
> the type hierarchy is
>
> 2: TextEditor -> StatusTextEditor ...
> 3: TextEditor -> ExtendedTextEditor -> StatusTextEditor
>
> and the method I override (createPartControl) is implemented in 2 in
> StatusTextEditor, but in 3 in ExtendedTextEditor and not in
StatusTextEditor
> (but it is declared in their common supertype WorkbenchPart in 2 and 3).
>
> This means that with respect to the API referenced in my source file there
> has been no change, and I would not have expected the compiler to hardwire
> the call to super.createPartControl() as directed to StatusTextEditor. But
> this is what the Eclipse compiler apparently does. I compared it with a
> similar scenario compiled with the Sun javac, which didn't.
>
> If I understand this correctly, then there is a difference in the
behaviour
> of the Eclipse compiler and Sun javac, which results in this case in a
more
> specific reference in the bytecode created by the former. And in
situations
> like in my example, this has consequences for binary compatibility, which
> wouldn't necessarily be there with the compile strategy of the latter. (I
> presume that it may have its advantages too, maybe in respect to
performance
> or sth. like that.)
>
> Is there some document or discussion in respect to that behaviour of the
> compiler somewhere? Possibly stating the reasons for implementing it that
> way, and discussing the relations to the binary compatibility rules in the
> JLS?
>
> Thx again & ciao,
> Leif
>
> "Chris Laffra" <Chris_Laffra@oti.com> schrieb im Newsbeitrag
> news:bkthge$9s$1@eclipse.org...
> > You cannot develop on version 3.0 and run on 2.1.
> > Your code was compiled against classes with different implementations.
> > Load your plugin in 2.1, rebuild it, package it, and it should run
better.
> >
> > 2.x and 3.x are not ensured binary compatble. Some API will change.
> >
> > Chris
>
>
|
|
|
| Re: Binary compatibility / Porting guide [message #136066 is a reply to message #136025] |
Thu, 25 September 2003 14:20 |
| Eclipse User |
|
|
|
Hi Chris,
Thanks again; I'm sorry to be so insistent, but your example isn't to the
point. It involves only two classes. A class has always a reference to its
superclass, so this is trivial.
But compare these:
package apack;
public class Hyper { public void x() {} }
-
package bpack;
import apack.Hyper;
public class Super extends Hyper {}
-
package bpack;
public class Sub extends Super { public void x() { super.x(); } }
Sun javac:
Compiled from "Sub.java"
public class bpack.Sub extends bpack.Super{
public bpack.Sub();
Code:
0: aload_0
1: invokespecial #1; //Method bpack/Super."<init>":()V
4: return
public void x();
Code:
0: aload_0
1: invokespecial #2; //Method bpack/Super.x:()V
4: return
}
Eclipse compiler:
Compiled from "Sub.java"
public class bpack.Sub extends bpack.Super{
public bpack.Sub();
Code:
0: aload_0
1: invokespecial #9; //Method bpack/Super."<init>":()V
4: return
public void x();
Code:
0: aload_0
1: invokespecial #18; //Method apack/Hyper.x:()V
4: return
}
The difference here is that the version compiled by the Eclipse compiler
has directly resolved the reference to the actual implementation, whereas
the Sun-compiled version leaves this job to the runtime, meaning later
binding.
In fact, nowhere in Sub anything has to be known about Hyper. IMHO this is
nearer
to what I take to be the idea behind late binding and polymorphism.
I'm also not quite so sure whether it is JLS compliant, but I'm not an
expert at that (that's why I'm asking). I could not really make up my mind
from reading the specs so far, since they are so formal. But I see how it
can be of real concern for e.g. software companies that plan to use Eclipse
(which would mean automatically to use the Eclipse compiler).
Suppose Super is public API of a class library which is used by some end
customer who
subclasses it like Sub. (This is commonly the case with a lot of class
libraries.) The vendor of
the library could easily change the implementation above Super if he could
rely on a behaviour
like that of the Sun compiler. And it is common to put abstraction layers
into class hierarchies (as the example with the TextEditor shows). So this
is probably more than just a theoretical problem, I think.
If you could point me to more information or documents on the web that
discuss the issue in connection with the Eclipse compiler, I would be very
grateful.
Ciao,
Leif
"Chris Laffra" <Chris_Laffra@oti.com> schrieb im Newsbeitrag
news:bkv71p$ibk$1@eclipse.org...
> This is Java spec behavior, exactly as the language dictates it.
> I actually confirmed it for you:
>
> $
> $
> $
> $ cat A.java
> public class A { public void foo() { } }
> $ cat B.java
> public class B extends A { public void foo() { super.foo(); } }
> $ javac A.java B.java
> $ cfdump -b B.class
> public class B extends A
> {
> public void <init>();
> public void foo();
> }
> public void <init>()
> 0 JBaload0
> 1 JBinvokespecial 1 A.<init>()V
> 4 JBreturn
>
> public void foo()
> 0 JBaload0
> 1 JBinvokespecial 2 A.foo()V <----- calls A.foo
> 4 JBreturn
>
> $
> $
> $
>
> Chris
>
> "Leif Frenzel" <lfrenzel@innoopract.de> wrote in message
> news:bkuo6r$19p$1@eclipse.org...
> > Hi Chris,
> >
> > Thanks for your answer. I read the documents that stated that APIs will
> > change between 2.x and 3.0 versions. So I see the solution to that
> > particular problem is to develop or at least compile and deploy from a
2.1
> > platform. Is there already a draft for that porting guide mentioned in
the
> > Project Plan?
> >
> > But there is still a more general point I'm not sure about : In the
> example
> > I wrote I extend a class that _has_ changed from 2.x to 3.0 with respect
> to
> > its superclass set and the precise location of the overriden method.
> Namely,
> > the type hierarchy is
> >
> > 2: TextEditor -> StatusTextEditor ...
> > 3: TextEditor -> ExtendedTextEditor -> StatusTextEditor
> >
> > and the method I override (createPartControl) is implemented in 2 in
> > StatusTextEditor, but in 3 in ExtendedTextEditor and not in
> StatusTextEditor
> > (but it is declared in their common supertype WorkbenchPart in 2 and 3).
> >
> > This means that with respect to the API referenced in my source file
there
> > has been no change, and I would not have expected the compiler to
hardwire
> > the call to super.createPartControl() as directed to StatusTextEditor.
But
> > this is what the Eclipse compiler apparently does. I compared it with a
> > similar scenario compiled with the Sun javac, which didn't.
> >
> > If I understand this correctly, then there is a difference in the
> behaviour
> > of the Eclipse compiler and Sun javac, which results in this case in a
> more
> > specific reference in the bytecode created by the former. And in
> situations
> > like in my example, this has consequences for binary compatibility,
which
> > wouldn't necessarily be there with the compile strategy of the latter.
(I
> > presume that it may have its advantages too, maybe in respect to
> performance
> > or sth. like that.)
> >
> > Is there some document or discussion in respect to that behaviour of the
> > compiler somewhere? Possibly stating the reasons for implementing it
that
> > way, and discussing the relations to the binary compatibility rules in
the
> > JLS?
> >
> > Thx again & ciao,
> > Leif
> >
> > "Chris Laffra" <Chris_Laffra@oti.com> schrieb im Newsbeitrag
> > news:bkthge$9s$1@eclipse.org...
> > > You cannot develop on version 3.0 and run on 2.1.
> > > Your code was compiled against classes with different implementations.
> > > Load your plugin in 2.1, rebuild it, package it, and it should run
> better.
> > >
> > > 2.x and 3.x are not ensured binary compatble. Some API will change.
> > >
> > > Chris
> >
> >
>
>
|
|
| |
| Compliance level [message #136131 is a reply to message #136076] |
Thu, 25 September 2003 15:32 |
| Eclipse User |
|
|
|
Hi Olivier,
jupp, I see where your question points to. I compare with javac 1.4.2, the
Eclipse compiler had compliance 1.3 set. Switching it to 1.4 results in the
same output for both compilers. Therefore, the real difference is between
different code compliance levels, not between the linking strategy of the
compilers. So that's really interesting, thx for showing it to me.
Still I don't completely understand it ...
1) The Sun docs read
> The compiler defaults to the 1.3 behavior if the -source flag is not used.
( http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.h tml)
and I didn't use it. So I would think javac runs 1.3 compliant, which would
then mean the Eclipse compiler has different behaviour for levels 1.3/1.4,
whereas the javac does the same in both levels.
2) I thought the code compliance flag was just about the assertions. I never
heard that it influences also the linking behaviour. (There is also nothing
about that in the Eclipse docs.) Is there some info about that you could
point me to?
Thanks again & ciao,
Leif
"Olivier Thomann" <olivier_thomann@ca.ibm.comNOSPAM> schrieb im Newsbeitrag
news:3vc6nvgflcnncmth8mqnjhveb6jnkl48op@4ax.com...
> Le Thu, 25 Sep 2003 20:20:48 +0200, "Leif Frenzel"
> <himself@leiffrenzel.de> a
|
|
|
Goto Forum:
Current Time: Sat Jun 07 10:05:48 EDT 2025
Powered by FUDForum. Page generated in 0.03762 seconds |
Home