Re: [DISCUSS] Was: Re: [VOTE] Theory based development
On Jan 22, 2014, at 657AM, Peter j...@zeus.net.au wrote: Startable only had one purpose: To provide the implementor a thread of execution after construction completes. It's provided by the the infrastructure to the service implementation, what the implementor does with it is their business. By itself it's harmless, but the point being here is that the Startable interface semantics cannot enforce the problem you are trying to solve. One alternative was, for our service implementations to be moved to abstract classes and threads started and exporting performed in stateless concrete classes, the other was to removal all final field modifiers, Startable was simple and seemed more elegant. That's about it in a nutshell, sorry if you got the impression it had another purpose. The problem with the tests; they've had bug fixes too, so people have trouble trusting them. The section of code you've found in Outrigger is ugly but correct, ideally sync would be the responsibility of resource but in this case it's external. Synchronizing on local variables is usually a bad idea. If the object that resource points to will *always* be the same, then the synchronized(resource) block does in fact use that quasi-global object's monitor. IMO it would be a better practice to use a synchronized wrapper here. Dennis
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
I was more thinking along the lines of encouraging best practise. Right now, if you read River's service implementations, every single one uses final fields and publishes partially constructed service reference to other threads, the hotspot compiller is free to reorder so these, so threads see partially constructed objects and default values for final fields. The reference shared during export is never updated, so threads carrying method invocations from remote clients never see a safely published reference and there is no way to obtain one at present. If people want it enforced, I could create a private class, that extends SecurityManager, walks the call stack, checks if export is being performed during construction, then use reflection to check for final fields and throw an exception if it does, but that doesn't ensure the service is thread safe. Presently we expect service implementations to be thread safe (remote method invocation is performed via a thread pool), but River doesn't provide an easy way for implementors to use final fields. Services can also use static methods and writeReplace, provided they're not using the starter kit. Peter. - Original message - On Jan 22, 2014, at 657AM, Peter j...@zeus.net.au wrote: Startable only had one purpose: To provide the implementor a thread of execution after construction completes. It's provided by the the infrastructure to the service implementation, what the implementor does with it is their business. By itself it's harmless, but the point being here is that the Startable interface semantics cannot enforce the problem you are trying to solve. One alternative was, for our service implementations to be moved to abstract classes and threads started and exporting performed in stateless concrete classes, the other was to removal all final field modifiers, Startable was simple and seemed more elegant. That's about it in a nutshell, sorry if you got the impression it had another purpose. The problem with the tests; they've had bug fixes too, so people have trouble trusting them. The section of code you've found in Outrigger is ugly but correct, ideally sync would be the responsibility of resource but in this case it's external. Synchronizing on local variables is usually a bad idea. If the object that resource points to will *always* be the same, then the synchronized(resource) block does in fact use that quasi-global object's monitor. IMO it would be a better practice to use a synchronized wrapper here. Dennis
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
Given the number of users on this mailing list, and the tiny number of votes, it seems that many people are abstaining. Why is this such a touchy issue? -- Dawid Loubser da...@travellinck.com Op Ma, 2014-01-20 om 09:25 -0500 skryf Greg Trasuk: On Jan 20, 2014, at 3:00 AM, Peter Firmstone j...@zeus.net.au wrote: Greg, We need to define the terms of reference for our discussion of proposed changes. We need to avoid emotive arguments, like “complete red herring”, “cascade of further failures” and “sweeping changes”. I believe a much greater risk is not fixing issues, I believe I can demonstrate that, given the opportunity. I also encourage all who are interested to become involved. Which is why I’m asking you to vote on theory driven development: I will abstain from this vote. Cheers, Greg. signature.asc Description: This is a digitally signed message part
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
I can only give you my own thoughts and experiences, others may think differently. The current codebase was created through an experimental development process by Sun, it hadn't been compiled and tested on Java 5 until River took ownership. The code's now a tad on the brittle side, fixing something simple, often reveals unrelated latent bugs. A change in JDK version is also doing exactly that right now, see our windows 2008 JDK7 Jenkins build, 45 test failures. - Don't deploy on Java 7 yet is my advise. To change the codebase to a more theory driven design, means fixing code that works good enough, which also causes latent bugs to manifest. Making such a transition means fixing a lot of non compliant code, or releasing with some failing tests and risk latent bugs manifesting during deployment. Out of interest, Porter (Jini 2.1) was released with some tests disabled, including a stress test for Outrigger, StressTestInterleaved, that test now passes on qa_refactor. The benefit of these changes is more robust easier to maintain and develop code. The risk is we might unintentionally break something. This is one of those cases, where it's easy to criticise, but hard to do. The River community has spoken with their silence on this occassion. Unless some discussion indicates otherwise, I intend to let the River community decide when it's ready to integrate fixes from qa_refactor and will no longer be looking to merge and release. For that reason, I also reccommend reverting trunk, with the exception of Sim's recent work, which I have peer reviewed. Regards, Peter. - Original message - Given the number of users on this mailing list, and the tiny number of votes, it seems that many people are abstaining. Why is this such a touchy issue? -- Dawid Loubser da...@travellinck.com Op Ma, 2014-01-20 om 09:25 -0500 skryf Greg Trasuk: On Jan 20, 2014, at 3:00 AM, Peter Firmstone j...@zeus.net.au wrote: Greg, We need to define the terms of reference for our discussion of proposed changes. We need to avoid emotive arguments, like “complete red herring”, “cascade of further failures” and “sweeping changes”. I believe a much greater risk is not fixing issues, I believe I can demonstrate that, given the opportunity. I also encourage all who are interested to become involved. Which is why I’m asking you to vote on theory driven development: I will abstain from this vote. Cheers, Greg.
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
On Jan 20, 2014, at 3:00 AM, Peter Firmstone j...@zeus.net.au wrote: Greg, We need to define the terms of reference for our discussion of proposed changes. We need to avoid emotive arguments, like “complete red herring”, “cascade of further failures” and “sweeping changes”. I believe a much greater risk is not fixing issues, I believe I can demonstrate that, given the opportunity. I also encourage all who are interested to become involved. Which is why I’m asking you to vote on theory driven development: I will abstain from this vote. Cheers, Greg.
