Re: [Java-player-users] ClassCastException: javaclient2. requestInterface ...

[Radu B. R. <ru...@cs...>]

Hi Shawn,

Sorry for replying so late. Always good to see new users on this list! 
Keeps the Javaclient development sort of... ermm, alive. :)

Shawn Lavelle wrote:
> Hello All,
>
>    I'm new to the list, so please forgive me if this has been 
> addressed. It is quite similar to the issue Radu encoutered in this 
> thread: 
> "http://sourceforge.net/mailarchive/forum.php?thread_id=9923107&forum_id=44859". 
>  Hugo presented a dirty hack to fix it, but it seems, well, dirty.
>
>    The problem we've encountered here pertains to requesting 
> interfaces.    At the end of this note I included a copy of 
> requestGripperInterface for  reference. My first question is, what 
> version of Java this is compiled against and why are generics not 
> used, or a general requestInterface where you pass in the interface 
> you want?  Since all these functions are identical save for 
> "PLAYER_<interface>_CODE" or such they could easily be combined into 
> one method.

That is a good idea, and I thought about it for some time now. I will 
try to implement something like that maybe right after Player 2.0.2 
comes out.

>
>    The second question is more of a bug and also is of more 
> consequence.   Similar to the referenced post concerning reading, the 
> two methods requestDeviceAccess and isReadyRequestDevice come 
> immediately after each other.  However, there is no guarantee that 
> stage has returned the device yet, especially in a resource limited 
> platform. This call then returns null.  Let's assume, for a minute, 
> that the programmer decides to assume things have succeeded and a 
> request is then made for a different device.  It executes the 
> requestDeviceAccess method but before isReadyRequestDevice is called, 
> stage returns the first interface while the 2nd is now delayed.  
> isReadyRequestDevice now returns true but the wrong interface is 
> stored in newpd.  With how this is coded, the 2nd requestInterface 
> will attempt to cast newpd as the 2nd interface. This will throw the 
> ClassCastException as newpd contains the first interface.
>
>    Possible solutions:
> 1) Typecheck!
> 2) Wait/Sleep for 100ms before checking isReadyRequestDevice
> 3) Poll newpd, saving them as they come in. On future requests for the 
> device with same parameters use the already returned devices listing.
>
>   What are your thoughts on this?  Is this better handled by the 
> developer's alias instead of this user's alias?  Thank you for your 
> assistance!

Yup. That is an ugly piece of code and we need to change it ASAP. For 
the last few weeks/months I didn't do any real Javaclient development 
since I am not using it for my current project. I would gladly accept 
any tested patches for that!  I will have a look at the code and see if 
I can come up with something too.

Thanks a lot,
Radu.

>
> ~ Shawn M Lavelle
>   ATCorp R&D
>
>
> public GripperInterface requestInterfaceGripper (int index, int access) {
>         requestDeviceAccess (PLAYER_GRIPPER_CODE, index, access);
>         if (isReadyRequestDevice ())
>             return (GripperInterface)newpd;
>         else
>             return null;
>     } 

-- 
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen