river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Tue, 02 Sep 2008 14:35:43 GMT
----- Original Message ----

> From: Niclas Hedhman <niclas@hedhman.org>
> To: river-dev@incubator.apache.org
> Sent: Tuesday, September 2, 2008 2:41:27 AM
> Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development issues
and ideas.
> On Tue, Sep 2, 2008 at 4:23 AM, Wade Chandler
> wrote:
> > What I'm getting at is those TOs can hold some logic used on both sides in the 
> situations where needed, and that logic itself is not going to be serialized for 
> instances held within a JavaSpace. The logic I'm talking about is of course 
> state mantainence as it relates to properties or JavaBean specifications. The 
> only thing being marshaled are the fields not the methods. Just being able to 
> encapsulate some things means you can control state and double duty those 
> objects a bit better...more protection even in logic you intend to always be 
> secure. And, that logic will not be marshaled, just the state or fields.
> AFAIK, you can serialized anything into the JavaSpace. The public
> field requirement is only for what can be used to look up those
> instances later.
> The rest of this discussion is mostly about programming patterns, and
> every developer thinks he knows better.... ;o)

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.

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:

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

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?

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.

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

One can argue that is good or bad, but the real argument on whether something is good or bad
shoud 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.



View raw message