Re: Don't let Jini Standards become an impediment to development

On 10/09/2015 11:48 AM, Bryan Thompson wrote: I am happy to take on the documentation change. My preference would be for a FAQ. But I am also strongly in favor of getting custard Apple into SVN in org.apache.river.concurrent and moving ahead based on what we have now for 3.0. Done. Bryan

Re: Don't let Jini Standards become an impediment to development

Great! I see this checked in under the river_qa-refactor-namespace branch into the org.apache.river.concurrent package along with the test suites for that package and updates to the poms for the various services and the delete of the apple-custard jars. ant build succeeds for me after svn update

Re: Don't let Jini Standards become an impediment to development

Peter have you ever constructed a demo of a massively active Javaspace app with and without reflection use for entry deserialization? It might be a great thing to have those numbers to help everyone recognize what you (and I) have seen as impeding implementation/architectural attributes.

Re: Don't let Jini Standards become an impediment to development

No. At least for now, the code is correct (defensive copying, using Cloneable). I'll see how I go with my security improvements first, I don't want to put lots of effort in, only to have it struck down. I've previously had a few months of work rejected without as much as a single code

Re: Don't let Jini Standards become an impediment to development

Greg, Thanks for putting the time & effort to look up these links. Primitive fields are an interesting case, I guess they had to be disallowed, because the serial form of an int is different from an Integer, at least for java Serialization. The performance trade off I mentioned relates to

Re: Don't let Jini Standards become an impediment to development

It's worth noting that volatile is not excluded by the Entry specification. This doesn't provide any performance benefit whatsoever, but it does provide visibility guarantees between threads. There is no atomicity... Greg, what are your thoughts? Regards, Peter. On 9/09/2015 7:00 PM,

Re: Don't let Jini Standards become an impediment to development

> On Sep 9, 2015, at 8:05 AM, Peter wrote: > > It's worth noting that volatile is not excluded by the Entry specification. > > This doesn't provide any performance benefit whatsoever, but it does provide > visibility guarantees between threads. There is no atomicity… > >

Re: Don't let Jini Standards become an impediment to development

I have found this to be a very interesting conversation. My own bias is, we are talking about 4.0. Let's focus on releasing 3.0 ;-) I completely understand Peter's concerns about reasoning about visibility for concurrency. I understand from Greg that the visibility comes from the network

Re: Don't let Jini Standards become an impediment to development

Peter, It is absolutely essential to do this in 3.0, rather than e.g. in 3.1? I propose freezing 3.0 except for fixing significant regressions and integrating custard-apple, so we can get it out the door. Patricia On 9/9/2015 4:04 PM, Peter wrote: In order to enable defensive copying of

Re: Don't let Jini Standards become an impediment to development

Standards become an impediment to development In order to enable defensive copying of Entries within SDM or LookupCache, as per Greg's suggestion, we need to make AbstractEntry implement Cloneable. At present, ServiceItem is Cloneable, but only a shallow copy of the attributes array is made, so

Re: Don't let Jini Standards become an impediment to development

In order to enable defensive copying of Entries within SDM or LookupCache, as per Greg's suggestion, we need to make AbstractEntry implement Cloneable. At present, ServiceItem is Cloneable, but only a shallow copy of the attributes array is made, so user expectations won't be realised, unless

Re: Don't let Jini Standards become an impediment to development

I am happy to take on the documentation change. My preference would be for a FAQ. But I am also strongly in favor of getting custard Apple into SVN in org.apache.river.concurrent and moving ahead based on what we have now for 3.0. Bryan On Wednesday, September 9, 2015, Patricia Shanahan

Re: Don't let Jini Standards become an impediment to development

So can we capture this information about snapshots in the service interface javadoc? For example, LookupCache:: ServiceItem [] lookup(ServiceItemFilter

Re: Don't let Jini Standards become an impediment to development

> On Sep 9, 2015, at 10:20 AM, Bryan Thompson wrote: > > I have found this to be a very interesting conversation. My own bias is, > we are talking about 4.0. Let's focus on releasing 3.0 ;-) > Don’t get me started :-) > I completely understand Peter's concerns about

Re: Don't let Jini Standards become an impediment to development

It's also worth mentioning, while I was fixing a synchronization or concurrency bugs, I found it very hard to reason about the state of public mutable fields in a number of api objects, I'd do a lot of defensive copying and making sure I've published them safely, however it is difficult to

Re: Don't let Jini Standards become an impediment to development

Brian, That was my first reaction too, so I read up on why Entries were designed as they are, Entries are a collection of objects, they're not supposed to be objects themselves. They are used for searching / comparing serial form. I basically came to the conclusion that an Entry's is most

Re: Don't let Jini Standards become an impediment to development

Peter, Can you enumerate the cases here? Certainly there are the public fields for entries. I would be in favor of encapsulating that at some point. Bryan On Tuesday, September 8, 2015, Peter wrote: > It's also worth mentioning, while I was fixing a synchronization or >

Re: Don't let Jini Standards become an impediment to development

Document as effectively immutable by contract. User error if relies on publication of modified array contents? On Sep 8, 2015 6:48 AM, "Peter" wrote: > Brian, > > That was my first reaction too, so I read up on why Entries were designed > as they are, Entries are a collection

Re: Don't let Jini Standards become an impediment to development

> On Sep 9, 2015, at 12:30 AM, Peter wrote: > > Thanks Greg, > > Was it a case of; because we can't set final fields (well not without a > Permission anyway), that they shouldn't be included in Entry serialized > state, because then we can't deserialize them? > No, it’s

Re: Don't let Jini Standards become an impediment to development

Thanks Greg, Was it a case of; because we can't set final fields (well not without a Permission anyway), that they shouldn't be included in Entry serialized state, because then we can't deserialize them? I've done my best to fix the existing implementations, so hopefully they won't need

Re: Don't let Jini Standards become an impediment to development

The obvious thing is we've broken namespace compatibility with River 3.0. River 2.2 broke serialization compability with previous releases with LookupLocator, although River 3.0 works around this to be serialization compatible with all previous release versions of LookupLocator, including

Re: Don't let Jini Standards become an impediment to development

On 5/09/2015 1:49 AM, Greg Trasuk wrote: On Sep 4, 2015, at 5:26 AM, Dawid Loubser wrote: And given the vision, experience and efforts of people like Peter, it would almost be criminal to not break free from an old standard, to miss the potential of what may be.

Re: Don't let Jini Standards become an impediment to development

It seems like modularization + git would go a long way toward encouraging parallel development, innovation, and reducing the time between releases. I think attempting to maintain both pure backward compatible jini and forward evolution of river seems like a path for confusion. How are people to

Re: Don't let Jini Standards become an impediment to development

Absolutely - agree with the modularisation and git. After that, we can stick to straight semantic versioning for compatability - i.e. the Jini API (standard) can evolve into future, non-backwards-compatible versions where necessary. Dawid On 04/09/2015 13:13, Bryan Thompson wrote: > It seems

Re: Don't let Jini Standards become an impediment to development

In my opinion, the simple fact of the matter is that the existing user base of Jini is really tiny, and generally what can be considered "legacy". There is precious little new Jini development occurring - and probably all 10 of us worldwide are on this list :-) I have to agree with Peter's

Re: Don't let Jini Standards become an impediment to development

> On Sep 4, 2015, at 5:26 AM, Dawid Loubser wrote: > > And given the vision, experience and efforts of people like Peter, it > would almost be criminal to not break free from an old standard, to miss > the potential of what may be. > Speaking of which, I’ve always

Re: Don't let Jini Standards become an impediment to development

Yes, questions as to who is doing what with Jini keep popping up on River and Rio lists alike, but few are willing to share useful info about that. It was never figured out why. My experience is that Rio makes s much easier developer's life that I can hardly imagine doing without it. Any time

Don't let Jini Standards become an impediment to development

Threats to development and collaboration (as I see it): 1. The Jini standards are sacrosanct. 2. River is an implementation of the Jini Standards. 3. River has no public api other than the Jini standards. 4. Although public API can be improved in a backward compatible manner, the