| Migrating to 3.x TransferDropTargetListener [message #157082] |
Sat, 06 November 2004 17: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 #157091 is a reply to message #157082] |
Sat, 06 November 2004 17:46  |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
CL [dnoyeb] Gilbert wrote:
> 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?
>
>
>
>
Well after deep investigation turns out the gef version is already based
on the jface version.
I wonder then why they kept the old method when you could eliminate it
without any issues? Was the behavior different?
(or has the gef version just changed itself to comply?)
My solution was just to cast the type to the jface version and that
forced it into the proper method.
--
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 #157413 is a reply to message #157245] |
Tue, 09 November 2004 16:13 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Randy Hudson wrote:
> The old method and type remained for compatibility.
>
>
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 #157436 is a reply to message #157413] |
Tue, 09 November 2004 16:29 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
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.
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?
|
|
|
| Re: Migrating to 3.x TransferDropTargetListener [message #157474 is a reply to message #157436] |
Wed, 10 November 2004 02: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] |
Wed, 10 November 2004 03: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.17388 seconds
] 
Search
Help
Register
Login
Home
