river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Space/outrigger suggestions
Date Sat, 18 Dec 2010 00:03:25 GMT
There is one additional problem, the use of generics causes a narrowing of scope, the template
and return value must be the same type. The entry spec currently allows the template to be
a different class, a dummy class can be used instead. 

Once Generics are introduced into service api, at the boundaries of separately compiled code,
without the type safety checks performed by javac, only ill will come of it. Welcome to the
slippery slope of complication.

Time is precious, but seeing as you require me to do some work, it's only fair that you provide
me with an implementation, for me to break with a test case.

This implementation will require an Entry that contains a collection and a client that uses
objects from the collection.

The test case will put new entries into the space that contain collections also, these collections
will contain objects of a different type.

Your implementation will need to use a template that uses a wildcard for the collection, and
your client will need to access the objects contained within, using Generics to access their
implementation methods.

Then after I break it, I'll demonstrate that without Generics in a similar implementation,
the collection can be handled in a typesafe manner.

>From my experience, consistant reliable results build better developer confidence than
nice looking but broken api's. 

Peter.

----- Original message -----
> In this case, I believe one must first prove the contrary; prove there is a
> problem with generics in this case. Is there an example of where this proposal
> for JavaSpaces causes an issue. I don't know of any. I would be very surprised
> if one could give a working example of such an issue. We are talking about an
> Entry type. Whether this entry were passed into this call using generics or not,
> one could have a generic List in some field of some instance of their Entry.
> This can happen right now.
>
> 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: Peter <jini@zeus.net.au>
> > To: river-dev@incubator.apache.org
> > Sent: Fri, December 17, 2010 5:09:47 PM
> > Subject: Re: Space/outrigger suggestions
> >
> > There seems to be support for using generics in this case.
> >
> > If we can  develop some good documentation to explain why it works and why
> > it's  the  exception to the rule for using generics in service api, if this is
> > indeed  the  case, then I think it is acceptable.
> >
> > Do we have any good wordsmith's on  the list?
> >
> > I think we must do our due diligence and check for potential  problems.
> >
> > This will work for the simple case, but what about an entry  that contains a
> > collection, the user will expect the generic collection to be  typesafe but
> > runtime checks can't be performed.
> >
> > Instanceof  List<String> doesn't work for example.
> >
> > I'm worried this won't work  in all cases as expected.
> >
> > Are you prepared to do some research to proove  runtime type safety?
> >
> > If boilerplate code is the problem, is it possible  to use annotations to
> > perform checked type casts  instead?
> >
> > Cheers,
> >
> > Peter.
> >
> > ----- Original message  -----
> > > 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. 
 
> > > 
> > It
> > > also discounts the work of adding the cast every time (mandatory
> > > boilerplate
> > is
> > > bad).
> > >
> > > 2) Returning "Entry" is what the  method signature promises now, but it's
> not
> > > what the space specification  promises.      The read/take family of methods
> > has a
> > > semantic gap between  what is contractually promised and what is checked by
> > the
> > > compiler, and  generics can close that gap.
> > >
> > > ---
> > >
> > > I think I may  still be missing something when it comes to your point about
> > > "separate  compilation".      In the case of using generics at the method
> level
> > >  (again, not the class level), the compiler not resolves on each method 
> > call,
> > > does it not?      How then would we get in trouble with different  compilation
> > times?
> > >
> > > With the definition:
> > > public <T  extends Entry>  T read(T template, Transaction txn, long 
> timeout)
> > >
> > > Foo foo = space.read(someFoo,t,0); //Fine
> > > Bar  bar = space.read(someBar,t,0); //Also fine
> > >
> > > Granted, if the space  had previously seen some prior version of Foo, that's
> > a
> > > runtime kind of  problem, but that's a runtime problem with or without the
> > >  generic...
> > >
> > > Perhaps another example or a pointer to some  resources to read would
> clarify
> > > this for me.      (If you have the  time.)
> > >
> > > jamesG
> > >
> > > -----Original Message-----
> > >  From: "Peter Firmstone" <jini@zeus.net.au>
> > >
> > > The  alternative method signature that is typesafe for James:
> > >
> > > public  Entry read(Entry template, Transaction txn, long timeout);
> > >
> > > The  client knows the template's class type, the class cast isn't much
> > > work  for the client developer.  Simpler is best I think, Generic's offer
> > > no  benefit for Service API.
> > >
> > > Hope this helps to clear it  up.
> > >
> > > Cheers,
> > >
> > >  Peter.
> > >
> > >
> > >
> > > Patricia Shanahan wrote:
> > > > I'm  working on a replacement FastList that assumes JDK1.5 or later,
so
> > > >  that I can depend on the new memory model and some of the
> > > >  java.util.concurrent features.
> > > >
> > > > Do you advise using, or  avoiding, generics in its definition?
> > > >
> > > > Patricia
> > >  >
> > > >
> > > > On 12/14/2010 2:22 PM, Peter wrote:
> > > >  > Generics are replaced with casts in bytecode.  All typesafe checks
> > >  > > are done at compile time and the generic replaced with a cast. 
If
> > > > > clients are compiled separately, this check won't occur,  and the
cast
> > > > > will be unchecked at runtime.
> > > >  >
> > > > > If clients with identical bytecodes or type casts use  javaspace
it
> > > > > will work, if separately compiled clients with  different type casts
> > > > > try to use the same space service, it  will fail with class cast
> > > > > exceptions at runtime.
> > > >  >
> > > > > However since your T template is declared as a method  parameter,
the
> > > > > javaspace service can check the class name at  runtime and only
return
> > > > > that type.  This must be done in the  javaspace service implementation.
> > > > >
> > > > > Only then  will your generic method be typesafe.  So yes it will
work,
> > > > >  but I want to make sure the complications of generics in separately
> > > >  > compiled code is well understood. It is not simple, but can be
done
> > >  > > with due care.
> > > > >
> > > > > Users are going to  have a hard time understanding how to implement
> > > > > generics in  their service implementations, it is fraught with
> > > > > pitfalls  that may not bite until after deployment.
> > > > >
> > > > >  User devs expect generics to make life simpler, but it has the
> > > > >  opposite effect in remote code.
> > > > >
> > > > > We're either  going to have to document the use of generics in service
> > > > > api  really well, or prohibit them.
> > > > >
> > > > > I think  because it's possible it should be allowed, but we have
to
> > > > >  document it well as an advanced feature that places the type check
> > > >  > burden on the service implementation.
> > > > >
> > > > >  Cheers,
> > > > >
> > > > > Peter.
> > > > >
> > >  > > ----- Original message -----
> > > > > > Perhaps you could  unpack your statement about generics for
me a
> > > > > > bit.            Are you
> > > > > > saying this wouldn't work?
> > > > >  >
> > > > > > public<T extends Entry>  T read(T template,  Transaction
txn, long
> > > > > > timeout)
> > > > > >  (... with similar modifications to the other methods)
> > > > >  >
> > > > > > The generic is defined at the method-level,  enforcing that
the type
> > > > > > returned is
> > > > >  > the type of the template (and that the template extends Entry). 
       
> > > > > > This is,
> > > > > > indeed, the current  contractual obligation of the method.
> > > > > >
> > > > >  > It would be unfortunate if we couldn't add this, because this
would
> > >  > > > save our
> > > > > > users a cast every time they used  JavaSpace, but there may
be a
> > > > > > technical hurdle
> > >  > > > which I'm not understanding.
> > > > > >
> > > >  > > Anyway, thought I'd attempt to clarify, since last time there 
was
> > > > > > confusion over
> > > > > > whether I was  asking for method-level generics or class-level
> > > > > > generics  (the
> > > > > > latter would break JavaSpace generally).
> > >  > > >
> > > > > > jamesG
> > > > > >
> > > >  > > -----Original Message-----
> > > > > > From: "Peter"<jini@zeus.net.au>
> > > > > >  Sent: Tuesday, December 14, 2010 6:28am
> > > > > > To: river-dev@incubator.apache.org
> > >  > > > Subject: Re: Space/outrigger suggestions
> > > > >  >
> > > > > > I believe we can create jini community  standards.
> > > > > >
> > > > > > If the service api is  different, it is not breaking backward
> > > > > > compatibility,  it
> > > > > > is simply a different service.  A bridging service  smart
proxy can
> > > > > > implement
> > > > > >  javaspace and utilise the new service, allowing legacy clients
to
> > > >  > > utilise the
> > > > > > new service.
> > > > >  >
> > > > > > You could call it Balinda, Borne again Linda.  ;)
> > > > > >
> > > > > > With generics and service api,  compile time generic replacements
> > > > > > must be the
> > >  > > > same, otherwise a runtime class cast exception will occur. 
  This
> > > > > > will work when
> > > > > > T is replaced  by the same class, but will break when it isn't
in
> > > > > >  separately
> > > > > > compiled code.  Generics that are specific  will work.
> > > > > >
> > > > > > Cheers,
> > > >  > >
> > > > > > Peter.
> > > > > >
> > > > >  >
> > > > > >
> > > > > >
> > > > > > -----  Original message -----
> > > > > > > Who controls the JavaSpace  API specification? Is it something
we
> can
> > > > > > > change, as  part of River, or do we just have an implementation?
> > > > > >  >
> > > > > > > Should we be considering designing RiverSpaces,  similar
to
> > JavaSpaces
> > > > > > > but with an updated API,  including generics, more use
of
> > collections,
> > > > > > > and  better naming?
> > > > > > >
> > > > > > > James -  if you have time, could you file a Jira issue?
That way,
> > these
> > > > >  > > ideas will not get lost in the mail archives.
> > > > > >  >
> > > > > > > Patricia
> > > > > > >
> > >  > > > > On 12/14/2010 12:33 AM, James Grahn wrote:
> > > > >  > > > I have a small list of suggestions for javaspace/outrigger, 
> > largely
> > > > > > > > derived from my experience creating a  wrapper for
space
> > functionality
> > > > > > > > and direct  usage prior to the creation of that wrapper.
> > > > > > >  >
> > > > > > > > Many of these suggestions involve breaking  backwards
> > > > > > > > compatibility, so
> > > > >  > > > many tears will be shed and perhaps we'll decide
against 
> > implementing
> > > > > > > > any of these. But, I'm hoping this  might lead to
some discussion
> > and
> > > > > > > > perhaps some  improvements.
> > > > > > > >
> > > > > > > >  ---
> > > > > > > >
> > > > > > > > 1) Generic  methods.
> > > > > > > > First, use generics in the method  signatures to
minimize casting,
> > in
> > > > > > > > this  manner:
> > > > > > > >
> > > > > > > >  public<T extends Entry>  T read(T template,
Transaction txn, long
> > >  > > > > > timeout)
> > > > > > > >
> > > >  > > > > Seems broadly like a win, if use of Java 1.5 idioms
is 
> > acceptable.
> > > > > > > > This
> > > > > > >  > is the only one I've mentioned before, and the reaction
was
> fairly
> > >  > > > > > positive on this list.
> > > > > > >  >
> > > > > > > > ---
> > > > > > >  >
> > > > > > > > 2) More collection-like naming of space  methods,
more
> consistency.
> > > > > > > >
> > > > >  > > > read, take, readIfExists, takeIfExists, write, snapshot, 
notify,
> > > > > > > > registerForAvailabilityEvent all have  fine names.
That is, they
> > > > > > > > properly
> > > >  > > > > describe the functionality and how the methods themselves 
relate
> > > > > > > > to one
> > > > > > > >  another.
> > > > > > > >
> > > > > > > > I do,  however, take issue with "contents", "take
(with a
> > > > > > >  > collection)",
> > > > > > > > and "write (with a  list)".
> > > > > > > >
> > > > > > > > I  would suggest the following renamings:
> > > > > > > > contents  ->  readAllExisting
> > > > > > > > take (with collection)  ->  takeAny
> > > > > > > > write (with list) ->    writeAll
> > > > > > > >
> > > > > > > > This  would eliminate the awkward overloading of
"take" and
> "write"
> > > > >  > > > while
> > > > > > > > bringing "contents" into a  consistent naming plan.
> > > > > > > >
> > > > > >  > > The goal is a naming scheme which clearly communicates 
> > functionality:
> > > > > > > > "exists/existing" suffix =  nonblocking call
> > > > > > > > "any" suffix = one or more  templates will be satisfied,
> > multi-return
> > > > > > > > "all"  suffix = all templates will be satisfied,
multi-return
> > > > > >  > > If unmodified, standard blocking call.
> > > > > > >  >
> > > > > > > > The clearer naming also points to new  functionality
we could
> > > > > > > > choose to
> > > >  > > > > support, namely:
> > > > > > > > readAll -  blocking call with all templates
> > > > > > > > readAny -  blocking call on any template
> > > > > > > > takeAllExisting -  nonblocking call with multiple
templates.
> > > > > > > >  takeAll - blocking call with all templates
> > > > > > >  >
> > > > > > > >
> > > > > > > >  Addendums:
> > > > > > > > 1) I'll admit that "any" is the  weakest part of
the syntax, as it
> > > > > > > > fails
> > >  > > > > > to connote the multi-return. I was stretching to
cover  the
> > current
> > > > > > > > "take
> > > > > > >  > (with collection)" semantics, which blocks until
at least one
> > > >  > > > > template
> > > > > > > > match is  available. Open to better suggestions.
> > > > > > > >
> > >  > > > > > 2) Though generally I dislike overloading methods, 
there is one
> > > > > > > > case I'm
> > > > > >  > > sympathetic to: overloading "all" and "allExisting"
methods to
> > >  > > > > > take in a
> > > > > > > > single  template or multiple templates. This would
save some calls
> > to
> > > > >  > > > Collections.singleton() for our users while maintaining
a 
> > consistent
> > > > > > > > return type for the method.
> > >  > > > > >
> > > > > > > > ---
> > > > >  > > >
> > > > > > > > 3) Collections or remote  iterators, not both.
> > > > > > > > "contents" returns a  remote iterator named "MatchSet",
while
> "take
> > > > > > > >  (with
> > > > > > > > collection)" returns a collection. I can  understand
the argument
> > > > > > > > behind
> > > >  > > > > both use cases, but not necessarily the argument
for using  both
> > > > > > > > simultaneously.
> > > > > >  > >
> > > > > > > > ---
> > > > > > >  >
> > > > > > > > 4) Exception soup.
> > > > > >  > > Javaspace methods return a vast cornucopia of possible
> > > > > > exceptions. 
> > I
> > > > > > > > would propose wrapping any Exceptions  bubbling up
to River users
> > > > > > > > to be
> > > >  > > > > wrapped in RiverException. Those few(?) who have
special
> > > > handlers
> > to
> > > > > > > > deal with problem conditions can  peek into the cause.
> > > > > > > >
> > > > > >  > >          From my observation, most libraries
are either taking  this
> > > > > > > > route (ala
> > > > > > >  > JAXB) or wrapping everything in runtime exceptions
(Spring,
> IIRC).
> > >  > > > > >
> > > > > > > > Presumably this  suggestion could be applied to all
of River, not
> > just
> > > > > >  > > JavaSpaces.
> > > > > > > >
> > > > > >  > > ---
> > > > > > > >
> > > > > > > >  5) Clearer javadocs.
> > > > > > > > The current Javaspace docs  are part protocol specification,
part
> > > > > > > >  implementation with some vital bits of information
squirreled
> > > > > > > > away
> > in
> > >  > > > > > obscure reaches.
> > > > > > >  >
> > > > > > > > For instance, in the 9 paragraphs  describing the
behavior of
> "take
> > > > > > > > (with
> > >  > > > > > collection)":
> > > > > > > > "If  there is at least one matching Entry available
in the space,
> > an
> > > >  > > > > invocation of this method must take at least one
Entry. If  more
> > > > > > > > than one
> > > > > > > >  matching Entry is available, the invocation may
take additional
> > > >  > > > > entries.
> > > > > > > > It must not take  more than maxEntries, but an implementation
may
> > > > > > > >  chose
> > > > > > > > to take fewer entries from the space than  the maximum
available
> or
> > > > > > > > the
> > > > >  > > > maximum allowed by maxEntries."
> > > > > > >  >
> > > > > > > > The above is a broad protocol  specification to implementers
(even
> > > > > > > > allowing  that the method may always return an empty
list ;-) ).
> > > > > >  > > Frustrating to users because the definition is so
amorphous.
> > >  > > > > >
> > > > > > > > It also takes some  doing to track down the fact
that the
> > > > > > > >  implementation
> > > > > > > > does, in fact, limit the number  of entries returned
from a "take
> > > > > > > > (with
> > >  > > > > > collection)". That tidbit is stored within the 
outrigger
> > *package*
> > > > > > > > documentation, which  reveals the setting and default
(only 100).
> > > > > > >  >
> > > > > > > >
> > > > > > > >
> > >  > > > > > Aside: In prior discussion, I believe the reason
for  using that
> > limit
> > > > > > > > was that the implementation  creates an array of
size
> > Minimum(limit,
> > > > > > > >  maxEntries)... and I think there's already a JIRA
bug to switch
> > > >  > > > > from the
> > > > > > > > array to a  collection. When we do, we should be
a bit more
> > > > > > > >  generous with
> > > > > > > > the default (or remove the  setting).
> > > > > > > >
> > > > > > > >  ---
> > > > > > > >
> > > > > > > > Anyway,  hope this stirs some discussion.
> > > > > > > >
> > > >  > > > > I'll be on vacation the rest of the month, so unfortunately 
my
> > > > > > > > participation in said discussion will likely  be
spotty (though
> > > > > > > > I'll try
> > > > >  > > > to look in). I've been meaning to push out these
recommendations 
> > for
> > > > > > > > some time, though, so I figured better now  than
waiting another
> > > > > > > > month.
> > > > >  > > >
> > > > > > > > jamesG
> > > > > >  > >
> > > > > > >
> > > > > >
> > > > >  >
> > > > > >
> > > > >
> > > > >
> > >  >
> > > >
> > >
> > >
> > >
> >
> >


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