river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: Space/outrigger suggestions
Date Fri, 17 Dec 2010 16:14:56 GMT
I am inclined to agree but isn't there another better solution.  Seems like there mist be but
maybe not

Sent from my iPhone

Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365

On Dec 17, 2010, at 8:09 AM, Tom Hobbs <tvhobbs@googlemail.com> wrote:

> 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, 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