----- Original Message ---- > From: Niclas Hedhman <[EMAIL PROTECTED]> > To: [email protected] > 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: 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. 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 needed. 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. Thanks, Wade
