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 15:58:16 GMT


----- 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, however 
>Java's generic  implementation suffers from erasure, the type safety disappears 
>after  compilation and relies on the fact that the code has been audited by the  
>compiler.
> 
> The binary signature of your method is the same as it is in  bytecode now, 
>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 this 
>works and just assume that generic's will work in all cases  for distributed 
>programming, then start using generics in their service api, it  will work at 
>first, but at some point in time, separately compiled code will be  mixed, the 
>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 problem, 
>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 compile 
>time, by the compiler and are  not checked again at runtime.  These checks are 
>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. Sure, 
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 here 
can be made for the cast. The client is assuming it is this "type" so they cast. 
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 some 
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 that 
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


Mime
View raw message