[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jdt-core-dev] Re: Java compiler questions
|
I'll post the answer to jdt-core-dev in case someone wants to jump in as
well.
This behavior is legite as per classloading restrictions. Now, the one
thing you may want to use is a 1.4 compiler, which will always use b.B as
the declaring class of the reference to foo(), even if B no longer
implements it, as long as the type of the receiver is B (which I guess it
is).
You can toggle the Eclipse compiler in 1.4 compliant mode, to achieve this
(Window>Preferences>Java>Compiler>JDK Compliance>Compiler Compliance
Level).
Jim des Rivieres
To: Philippe Mulet/SNZ/OTI@OTI
09/13/2002 05:21 cc: Benjamin Reed <breed@xxxxxxxxxxxxxxx>
PM Subject: Re: Java compiler questions(Document link: Philippe Mulet)
Philippe, Here's a puzzler for you. If you think its generally
interesting, the question should probably be reasked on the eclipse
newsgroup.
---jeem
Benjamin Reed
<breed@almaden.i To: Jim_des_Rivieres@xxxxxxx
bm.com> cc:
Subject: Java compiler questions
09/13/2002 11:03
AM
Jim,
I work with PvC and OSGi on an embedded Java Framework. We ran into an
interesting classloader problem recently that turned out to be a problem
generated by a compiler.
In a nutshell we have the following case:
class c.C extends class b.B which extends a.A.
a.A and b.B are loaded classloader X and c.C by Y.
In addition, Y can load b.B from X, but not a.A.
----
If a.A defines foo() and b.B overrides it, c.C can invoke foo() and
everything is fine. If the foo() method is removed from b.B, everything
still works fine. If c.C is recompiled against the new b.B, c.C will
get a class not found exception because c.C's byte code will now have a
reference in the constant pool to a.A that Y cannot resolve.
I have some questions regarding work arounds to this problem, but I want
to be sure that I understand the ramifications. Is there someone on
your team that I can talk to about them?
thanx
ben
