river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: Space/outrigger suggestions
Date Sun, 19 Dec 2010 16:47:03 GMT
Whoops, I had one other comment....

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?
>
>
> 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.
>
>
> 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
> 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);
>
>
I'm not sure this helps so much in cases where one is doing a
superclass-type match where the template can match a bunch of subclasses. It
doesn't do any harm either but I'll have to cast anyway....


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message