Wade Chandler wrote:
Thinking one knows better versus flexibility and giving the ability to
> do something are two different things. This is generally the hard part
> about working within a group to try to get something working better for
> ones own needs or others. Better, as I'm intending, doesn't mean better
> in the terms of a specific persons views necessarily, but better in the
> sense that something allows a developer to perform their role for a
> given domain or task in the way which makes best sense for a given and
> specific situation and not be locked into a particular pattern.
The discussions in the interview detail why the choice was made. Having a
public get/set pair which set a "constant" value is equivalent to having a
public member that you just assign and reference. So they chose to not require
the use of the public get/set method. A subtle but important issue I already
mentioned, is that they did not want to download code and have live objects in
the JavaSpace. That would be required for the get methods to be called.
Not having live objects is a big deal! It really makes certain things possible
that are otherwise not. It also creates certain limitations. If you need
something with live objects, try out my http://griddle.dev.java.net project.
It's not a production ready system. It does support live objects and
comparisons using method calls.
If you want everything that JavaSpaces provides, but more, than that's where I
think we are at in this discussion. That "more" requires something different
than what exists today. There are ramifications to the "system" when you make
those changes, and some of those (code versioning of live objects) can create a
problem if you don't do all the design for versioning (serialization issues and
data evolution as well) from the start.
Anyways, this is why it helps to discuss things. So, an entry can have any type of data,
>and that data may have any type of information wrapped however it is needed:
http://www.jini.org/wiki/Jini_Entry_Specification
It seems that link states that those fields, which may be of any type and
serializable,
>are still used as part of the template along with their fields, so are the
public
>fields still the only things used in comparison? If so, then the argument is
still
>valid as it negates any benefit of ecapsulation and comparison as private
fields of
>public properties are still not usable.
There is only one level that applies here. There are no live objects. What is
compared is the "Serialized" form of the public objects as view from the Entry
object's public fields values.
I just want to understand it correctly, but
>that link, per my understanding, states: only the public fields of any entry
or a
>fields fields are used for the template, and this means information must still
be
>copied around between narrowed and specific business objects and transfer
objects
>even when it does not make sense to do so in many situations and designs. If my
>understanding is incorrect, then the rest of this email is useless.
I'm confused by this slightly. Making sense, because an API/system design
requires it, is a given. Making sense because it's not what you want to do, or
what you have to do with another system/API is perhaps an opinion, or at most, a
point of interest worth discussion such as we are having here right?
Do JavaSpaces use Comparable or any other such comparison interfaces to make
>it possible for one to add their own comparison logic in the backend? I don't
>see this in the specifications. Are there any plans for such a template
>comparison interface to be added, or some other type of template descriptor
>on the books? Has the idea of beans as templates been passed around as being
>added to the specification?
Again, live code does not exist in the existing JavaSpace, so nothing is
"called" in any Entry object. The serialized form is compared for equality,
that's all the spec requires for the equality check.
Look, my argument is about making the technology more flexible; not to argue
>for the sake of arguing about what concept is better over all. I tend to not
>buy into such arguments as I have seen many things used in very innovative
>and good ways through the years. Look how Hibernate, Spring, and other
>libraries have influenced other specifications, and those are some very
>flexible libraries.
Each system/library has certain limitations and necessities in the use of them.
All we are trying to say is that JavaSpaces has no live code use. So anything
about "code" in objects, is not touchable. Again, this is why I created my
griddle project. During the development of the JavaSpaces05 spec, there was
this exact kind of discussion. So, I created griddle to give people something
to play with and see how it might be used. Didn't get a lick of interest in
such capabilities really, so I'm not sure how to weigh your assertive arguments
for such things against what the community has historically done.
I could easily make a simple annotation library which does what I'm
>advocating for people automatically by lazily creating a transfer object
>for a POJO or JavaBean, and that could live outside the specification.
>I just think it makes good sense to have that live inside the
>specification where such an extra library and logic are not always
>needed. I guess both things could live there though. An annotation
>library and the abiltiy to do more; this would allow many different
> uses and not lock folks into a single pattern by allowing pure
>transfer objects to be created without one needing to handle this
>logic manually, TO->BO and BO->TO, and also allow for those small
>and specific BOs in a given system to be used as both when needed.
My view is that separating a TO from a BO because of a "transfer" systems
requirements, is exactly the right thing to do. Creating a layer of abstraction
in the application software to keep an external system from impacting the
applications architecture is a good practice is it not?
For an HTTP web server resident servlet, would you have HTTP Request and
Response objects running around inside your application, or would they only be
visible at a particular interface?
One can argue that is good or bad, but the real argument on
>whether something is good or bad should come down to a specific
>use at a specific time within a specific design and not at some
>high level argument of how it is always a good or bad thing.
Yes, by and large, you can make this kind of assertion. But practically, all
kinds of architectural issues come into play with software because APIs are not
arbitrary. Many have specific requirements for order of operations data types
and behaviors (like hashCode() and equals()). I agree in principal with your
argument about the issues, but I'm not sure why your argument is pulling away
from the facts that exist so that we can focus on the issues that make it hard,
or impossible to do that and still meet the same service level agreements that
exist today with the existing JavaSpaces specification.
Live code in the JavaSpace would change everything.
Gregg Wonderly
