river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jgr...@simulexinc.com
Subject Re: Space/outrigger suggestions
Date Fri, 17 Dec 2010 16:22:29 GMT
I suppose I should point out that the Javaspace specification does guarantee that the type
returned in these cases is the type of the template.   If something else is returned, then
the space implementation is severely broken.    That being the case, why should we ask users
to check-and-cast?

Much more likely to my mind is that this change could expose some bugs in the client code
before they happen, as potential mis-casts would be discovered by the compiler (unless it
is a downcast, in which case traditional debugging would reveal the issue).

jamesG

-----Original Message-----
From: "Tom Hobbs" <tvhobbs@googlemail.com>
Sent: Friday, December 17, 2010 11:09am
To: river-dev@incubator.apache.org
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, 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