river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Space/outrigger suggestions
Date Fri, 17 Dec 2010 16:30:08 GMT
I don't know. Checks etc in this case, before calling read on the return or 
parameter type, just doesn't make any sense to me. If Jini returns an incorrect 
instance then it is simply in error per the specification. If you pass in a 
template, you expect to have that exact type, possibly an extension, returned. 
The only case I can imagine in my mind where that isn't the case, is an error in 
the underlying spaces impl. If that happens and needs to be checked for, then I 
would suggest using a different impl if you have production code, so I'm still 
confused to the counter argument to this proposal. This seems like over thinking 
it to me; which isn't always a bad thing. That or I'm just not yet convinced.

To me, if an impl dev is concerned about the impl working correctly, which they 
should be, there should be a check in the client API whether the returned is of 
the expected type. This should also be done on the impl server side per the 
specification (a match on an Entry must match the type or a sub type of the 
Entry). A correctly structured message should then be returned in the form of an 
Exception and logged as the impl is in error. I don't see that as a consumer 
concern. Can anyone explain why it should be? My argument is based on the 
specification where these are not arbitrarily loaded classes.


Wade Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor


----- Original Message ----
> From: Tom Hobbs <tvhobbs@googlemail.com>
> To: river-dev@incubator.apache.org
> Sent: Fri, December 17, 2010 11:09:55 AM
> Subject: Re: Space/outrigger suggestions
> I think the difference between generics vs not-generics in this case
> is to do  with expectations.
> If generics are used on the method signature then the  client developer
> *expects* not to encounter any runtime issues.  In  certain
> circumstances this expectation is incorrect.
> The method  signature without generics forces the client developer to
> do a runtime check  and a cast.  This is the only way to be safe in all
> cases.  Of  course every developer does a type check before they cast,
> don't they?   ;-)
> I think this (no generics) is the correct approach for  Outrigger,
> because it places 100% of the enforcement of this kind of safety  on
> the client developer.  That may not be the most convenient thing  for
> all developers, but it prevents a potentially difficult bug  hunt
> trying to work out why a cast failed when the developer is  convinced
> that it's the correct type - and the use of generics "proves"  that
> it's the correct type...
> On Fri, Dec 17, 2010 at 3:58 PM, Wade  Chandler
> <hwadechandler-apache@yahoo.com>  wrote:
> >
> >
> > ----- Original Message ----
> >
> >>  From: Peter Firmstone <jini@zeus.net.au>
> >> To: river-dev@incubator.apache.org
> >>  Sent: Fri, December 17, 2010 7:02:26 AM
> >> Subject: Re:  Space/outrigger suggestions
> >>
> >> jgrahn@simulexinc.com wrote:
> >>  >  public Entry read(Entry template, Transaction txn, long  timeout);
> >> >
> >> > That is indeed the original/current  method's signature.
> >> >
> >> > A couple of  points.
> >> > 1) "The client knows the []'s class type,  the class  cast isn't much 
>work" is
> >>an argument against all generics, not just   generics in this case.
> >>
> >>
> >>
> >> > It  ignores the additonal  specification power and type safety that  the
> >>generic provides.
> >>
> >> This is a  very  important comment, as it reflects the common understanding
> >>developers  have  of Generic's, this is true for code at compile time,  
> >>Java's generic  implementation suffers from erasure, the type  safety 
> >>after  compilation and relies on the fact that the  code has been audited by

> >>compiler.
> >>
> >> The  binary signature of your method is the same as it is in  bytecode  
> >>adding generic parameters won't change the binary method   signature.
> >>
> >> It is unfortunate that your example will  work with generic's,  which is 
> due to
> >>the template being passed as a  parameter, restricting the  return type to
> >>matching that of the  template, the problem is, people don't  understand why

> >>works and  just assume that generic's will work in all cases  for  
> >>programming, then start using generics in their service  api, it  will work 
> >>first, but at some point in time, separately  compiled code will be  mixed, 
> >>class cast's won't have been  checked by the compiler, then they'll  get 
>burnt by
> >>class cast  exceptions, after deployment, the worst time to catch  the  
> >>hence my comment, the type cast is simpler if performed by  the  client, 
>where it
> >>can be checked at  runtime.
> >>
> >> The type casts weaved into  bytecode by the  compiler are checked at 
> >>time, by the compiler and are  not  checked again at runtime.  These checks 
> >>not performed in code  that  has been compiled separately.
> >>
> >> Check out Jim  Waldo's  book:
> >>
> >>  http://www.amazon.com/Java-Good-Parts-Jim-Waldo/dp/0596803737
> >>
> >>  See also:
> >>
> >>  http://gafter.blogspot.com/2006/11/reified-generics-for-java.html
> >>
> >
> >  That taken into account, the proposal does make things better and works.  
> > there are some gotchas with generics, but you have to go on a case  by case
> > basis. Making something simpler makes a heap of sense, and in  this case, it
> > works well. I don't see the down side to this request. The  same argument 
> > can be made for the cast. The client is assuming it  is this "type" so they 
> > Same with the generics. The client assumes  it is this "type" which they are
> > programming into the case...lookup this  type with this template. Were there 
> > runtime mishap it would affect  it just the same. Just using a cast doesn't
> > ensure anyone builds in some  extra safety which will some how work around 
> > issue. Am I missing  something else about this proposal?
> >
> > Thanks,
> >
> >  Wade
> >
> >  ==================
> > Wade Chandler
> > Software  Engineer and Developer
> > NetBeans Dream Team Member and  Contributor
> >
> >  http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> >  http://www.netbeans.org
> >
> >

View raw message