----- Original Message ----
> From: Peter Firmstone <[email protected]> > To: [email protected] > Sent: Fri, December 17, 2010 7:02:26 AM > Subject: Re: Space/outrigger suggestions > > [email protected] 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
