Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dan.creswell@gmail.com
 designates 209.85.216.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=uTSUwFZtUHaavPxMz155Qe5aHjB9U+ZWLZgYH3E1Wvth474hYKfhCzze6Ipo1Kxq+m
         hIk9PBpLy/1/qAs79XFFbbaOh1Z74Uz0Adgap1G7Nt73xaDOGH7QMCVnyGTKoIE2VZ9D
         FvF36GUyFJ3dAqkD3X5eBERZpZNHzOZi8lXkU=
MIME-Version: 1.0
In-Reply-To: <991195.53568.qm@web33808.mail.mud.yahoo.com>
References: <1292659919.3679.22.camel@Nokia-N900-51-1>
	<AANLkTi=ovLx2ydG06FkFeZ0_K0GO5P7SCV2YcgH-sgRr@mail.gmail.com>
	<4D0DB6BD.4040907@zeus.net.au>
	<AANLkTinfb+pgxeWOJvoyimESVm2WFs+zavbaCZHKM9N8@mail.gmail.com>
	<991195.53568.qm@web33808.mail.mud.yahoo.com>
Date: Sun, 19 Dec 2010 16:09:05 +0000
Message-ID: <AANLkTimvhVPC+N0rjhxWgR2ru6H+nHwEOD6D428TzujP@mail.gmail.com>
Subject: Re: Space/outrigger suggestions
From: Dan Creswell <dan.creswell@gmail.com>
To: river-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0015175ca8766b10e80497c59feb

--0015175ca8766b10e80497c59feb
Content-Type: text/plain; charset=ISO-8859-1

On 19 December 2010 15:28, Wade Chandler <hwadechandler-apache@yahoo.com>wrote:

> But again, what you are describing, one can run into now if they do that
> with
> Entry. Does your current spaces implementation defend against what you are
> describing now?
>
>
>
Agreed, one can run into problems now but the current spec is silent such
that no type-checking is required/implied at all and thus one assumes a
"buyer-beware" type stance.

If we start to add in generics and such we are potentially at least, giving
the impression that things are totally safe and that everything is validated
at both compile and runtime. Now, I know impressions and specification are
two different things and we could ask that our users read all the specs in
detail rather than make assumptions based on impressions but, well, they
kinda don't in my experience.


> Adding some type checks like Peter and Nick mentioned on the types used in
> lookup I believe would work there to fix that. This makes me think what I
> wrote
> about this should just be something which is documented versus coded
> against may
> be what should be done in the interim with a proper fix later. Thus, start
> working on the cases we are talking about below, while documenting, and
> then
> work on those generics pitfalls in the impl. The pitfalls can occur now,
> and are
> completely orthogonal to the changes we have been talking about.
>
> Were one to use any spaces impl, or any API for that matter, they would
> have to
> know the outcome of choices they made with calls into the API. In this
> case,
> were one to have some arbitrary API which wasn't remote and given a similar
> case
> of the spaces specifications use of Entry, this use you are showing would
> be
> problematic. We can safely say anything giving returns based on matching
> this
> way and using generics in this case would have the same issue.
>
> Adding generics where they work is completely different than the cases
> where
> they are problematic. Currently, we are specifically talking about making
> the
> JavaSpace API interface use generics. That would be the methods of
> JavaSpace/05
> and MatchSet. Other cases can be reviewed after for the rest of the Jini
> APIs.
> Doing this for spaces allows one to merely write cleaner code when
> interacting
> with those interfaces.
>
>
Okay - so we narrow down the cases and end up with how much benefit for how
much work?

Purely based on my own experience I rarely (if ever) have trouble with cast
and only make use of a couple of JavaSpaces calls in any application I
write. The bulk of my code is JavaSpaces unrelated and thus there's limited
leverage/benefit for me in having generics on the JavaSpaces API.


>
> You write your Entry impl to the space. You can then retrieve it using a
> template of the same type and expect the return without using casting. The
>

Unfortunately, I remember the same argument being made about generics
originally. The result is a fractured reflections API that only does half
the job and the need for all sorts of bytecode hacks to construct e.g.
parameterised collections at runtime.


> spaces specifications already dictate that an Entry is only matchable if it
> is
> of the same type. Thus making read and take actually work well for generics
> when
> talking about the parameters to the spaces interface. EntryExtension<X,Y>
> is
> something we can't control now, we are specifically talking about
>
>
> EntryExtension instance = space.read(myEntryExtensionTemplate, null,
> 30000);
>
> versus
>
> EntryExtension instance = (EntryExtension)
> space.read(myEntryExtensionTemplate,
> null, 30000);
>
> There are cases where generics will get you into trouble with remote code,
> and
> in this case you are mentioning, any code given the same expectations
> without
> checks under the hood.
>
>
Don't get me wrong, I'm not against some experimentation but I'm somewhat
unclear on just how much benefit this gives me beyond saving me writing a
cast which isn't that much of a cost IMHO.


> Wade
>
>  ==================
> Wade Chandler
> Software Engineer and Developer
> NetBeans Dream Team Member and Contributor
>
>
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
>
>
>
> ----- Original Message ----
> > From: Dan Creswell <dan.creswell@gmail.com>
> > To: river-dev@incubator.apache.org
> > Sent: Sun, December 19, 2010 5:15:00 AM
> > Subject: Re: Fw: Re: Space/outrigger suggestions
> >
> > Is there a solid collection of use-cases anywheres? I've waded through
>  this
> > email thread and didn't see anything....
> >
> > Certainly I'd like to  see a little more detail on just where/when/how
> we're
> > proposing to use  generics as JavaSpaces users (forget implementors such
> as
> > me for now). i.e.  I'd like to understand what users want to do, then we
> can
> > figure out what's  viable.
> >
> > One area of concern for me would be how this could affect  matching
> semantics
> > within a space - consider:
> >
> > public class Test<T,  U> implements net.jini.core.entry.Entry {
> > public T aField;
> > public U  anotherField;
> >         public String  anId;
> > }
> >
> > Would you expect all instances of Test regardless of T and U  to be
> treated
> > as the same class of Entry and thus all searched? Similar  questions
> arise
> > when considering Collections as fields of Entry's.  Historically a
> Javaspace
> > would merely compare the marshalled value of the  collection against
> other
> > collections with no "deep matching" such that to all  intents and
> purposes
> > collections are used to carry objects around and  matching is done on
> other
> > "simple" fields.
> >
> > This somewhat speaks to the  problems we'd face as the result of two
> separate
> > compiles for two separate  clients and runtime classloading. One dev
> > specifies an  Entry:
> >
> > Test<Integer, String>
> >
> > Another  specifies:
> >
> > Test<String, Integer>
> >
> > If we assume we match on  Test instances ignoring the generics and only
> the
> > anId field is set, then  each client could end up with an instance of
> Test
> > that doesn't fit with it's  templated/specified at compile-time typing.
> >
> > At this stage, I'm not  entirely sold on generics for JavaSpaces as I
> can't
> > think of some suitably  neat use cases. I could imagine we might build
> some
> > wrapper for JavaSpaces  that constrains a client to deal in only certain
> > types of Entry along the  lines of the "check collection wrappers" Peter
> > mentions  elsewhere.
> >
> > Cheers,
> >
> > Dan.
> >
> > On 19 December 2010 07:39, Peter  Firmstone <jini@zeus.net.au> wrote:
> >
> > > Ok  thanks Nic, that's interesting, I stand corrected on erasure, seems
> > > it's  not entirely true.
> > >
> > > Any idea how we can enable runtime type  checks for Generics?
> > >
> > > So far we can get the type information, I  know it's preserved in
> > > bytecode from my experience with ASM and adding  Generics support to
> > > classdep, however, how does it stop me from setting  the field
> reference
> > > to another Collection, containing Integers, at  runtime, then returning
> > > it to the space?
> > >
> > > Even with  James' proposed javaspace method, which will work, the
> client
> > > typecast  is unchecked, it relies on the javaspace implementation to
> > > return the  correct type, which means you must trust the javaspace
> > >  implementation.
> > >
> > > This places a significant burden on the service  implementor.
> > >
> > > What about Generics in other Service  API?
> > >
> > > I use Generics for it's added type safety, but type safety  doesn't
> > > extend to distributed code, since it is a compiler check (hint:  I'd
> love
> > > to be pointed to a runtime type checker for Generics)  I'd  understand
> > > the attraction of using Generic's if it was the case, but I'm  failing
> to
> > > understand the relevance of Generic's without type safety,  could
> someone
> > > please explain it for me?
> > >
> > > Or are we  working on a tool to add type safety for Generic's to
> > > distributed  code?
> > >
> > > Sorry, the direction so far just appears to be, add  Generics to
> > > distributed code, without type safety checks, it seems type  checks
> might
> > > interfere with performance or something.
> > >
> > >  Regards,
> > >
> > > Peter.
> > >
> > >
> > >
> > > Niclas Hedhman  wrote:
> > >
> > >> On Sat, Dec 18, 2010 at 4:11 PM, Peter <jini@zeus.net.au>  wrote:
> > >>
> > >>
> > >>> if you have a field in an Entry  declared:
> > >>>
> > >>> public Collection<String>  names;
> > >>>
> > >>> In bytecode, because of erasure, its type  is Collection, this means
> I can
> > >>> take from the javaspace and set  the field to contain a Collection
> that
> > >>> doesn't contain String's  and the next time your code accesses it, a
> > >>> ClassCastException  will occur.
> > >>>
> > >>>
> > >>
> > >> That is not  correct. For fields, method return values and parameters,
> > >> the Type  is preserved (ParameterizedType it is called). So for the
> > >> above  example, do
> > >>
> > >>    Type[] types =  names.getClass().getGenericInterfaces();
> > >>
> > >> or something  like this for the declaration itself
> > >>
> > >>    Field  field = Main.class.getDeclaredField( "names" );
> > >>     field.setAccessible( true );
> > >>    Type type =  field.getGenericType();
> > >>
> > >>
> > >> In fact, quite a lot  of the things that people think are 'erased' are
> > >> actually  not.
> > >>
> > >> For instance, in a declaration  like;
> > >>
> > >> public interface  Abc<K,V>
> > >>
> > >> you can even retrieve the variable names  of 'K' and 'V' respectively
> > >> (those Type are called  TypeVariable).
> > >>
> > >>
> > >> Say what you want about Sun's  compromises in the generics system, but
> > >> it is far from "just  compiler checks".
> > >>
> > >>
> > >> In my project Qi4j  (http://www.qi4j.org), we use this extensively to
> > >> do sweet things  like;
> > >>
> > >>    Property<String>  fullname();  // in an interface
> > >>
> > >> to declare a  property instead of getter-setter-mania...
> > >>
> > >>
> > >>  Now, I am not saying that any of this should be deployed into River
>  at
> > >> all, just that more things are possible than you might  think.
> > >>
> > >>
> > >> Also Note; There are some small bugs  in Sun's JDK1.5 generics
> > >> compiler, where some corner cases are  handled incorrectly. The ones
> > >> that we have found are fixed in  1.6.
> > >>
> > >>
> > >>  Cheers
> > >>
> > >>
> > >
> > >
> > >
> >
>

--0015175ca8766b10e80497c59feb--