| Migrating to 3.x TransferDropTargetListener [message #157082] |
Sat, 06 November 2004 12:40  |
Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Looks like EditPartViewer no longer likes TransferDropTargetListener
from gef, and now only accepts
org.eclipse.jface.util.TransferDropTargetListener.
Is there any clean way to migrate my TransferDropTargetListener class
based on the gef version to the jface version?
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."
GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
|
|
|
|
|
|
|
| Re: Migrating to 3.x TransferDropTargetListener [message #157474 is a reply to message #157436] |
Tue, 09 November 2004 21:16  |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Randy Hudson wrote:
> I'm 99.9% sure you would get a method not found error. The .class file will
> contain a call to the old method, and the VM does not go walking up the
> supertype chain looking for a replacement method.
>
I think that is not correct. The VM does go walking up the supertype
chain looking for methods, that is what late binding is all about.
Unless you declared your method as final, java can not know before
runtime exactly what it needs to execute.
I just tested it, and unless my test was broken, this is true.
> If all code was recompiled, then it would work without source changes.
>
>
>>What is the compatability issue if the new method accepts a supertype of
>>what the old method accepts? Or is this not exactly true?
>>
>>
>>Was their different functionality within them? Java being a
>>late-binding language, I would think this would not be a problem right?
>
>
>
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber." John 10:1
GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
|
|
|
| Re: Migrating to 3.x TransferDropTargetListener [message #157482 is a reply to message #157474] |
Tue, 09 November 2004 22:02 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
CL [dnoyeb] Gilbert wrote:
> Randy Hudson wrote:
>
>> I'm 99.9% sure you would get a method not found error. The .class
>> file will
>> contain a call to the old method, and the VM does not go walking up the
>> supertype chain looking for a replacement method.
>>
>
> I think that is not correct. The VM does go walking up the supertype
> chain looking for methods, that is what late binding is all about.
> Unless you declared your method as final, java can not know before
> runtime exactly what it needs to execute.
>
> I just tested it, and unless my test was broken, this is true.
>
>
My test was broken. You are 100% correct. The called method is
determined at compile time.
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber." John 10:1
GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
|
|
|
Powered by
FUDForum. Page generated in 0.03605 seconds
Home