Thank you Luis & Bishnu for your support. For others who might be undecided, the intent of this vote is to establish rules to judge theoretical changes by, not to approve specific changes.
So why are we having this vote? Concurrency problems are very hard to generate reliable test cases for, when we find code that breaks simple rules set out in "Concurrency in practise", the Java memory model, or an expert interpretation of the JMM (eg concurrency interest mail list), we want to be able to fix it. To date, attempts to discuss fixing these bugs have been contraversial, despite proposed fixes not breaking backward compatibility. Alternative arguments have not been for alternate fixes, but maintaining the status quo, based on arguments around providing solid experimental evidence of failure. The intent of theoretical analysis based bug fixes is to maintain backward compatibility and improve stability by removing the possibility of race conditions. The goal of this vote is to remove contraversy in decisions about and provide centainty for bug fixes, so we can get on with development. This vote is not a vote for the bug fixes themselves. I'd also like to encourage the wider community to get involved, share your thoughts and votes, for or against. The outcome, whatever it may be, will provide certainty. Thanks & regards, Peter Firmstone. ----- Original message ----- > I am a remote expectator, but +1. > Thanks for all the effort. > > > On Sun, Jan 19, 2014 at 2:50 AM, Bishnu Gautam <bishn...@hotmail.com> > wrote: > > > > > Hi Peter > > I totally support theory based development.+1 > > RegardsBishnu > > > > > > Bishnu Prasad Gautam > > > > > > > Date: Sun, 19 Jan 2014 13:45:49 +1000 > > > From: j...@zeus.net.au > > > To: dev@river.apache.org > > > Subject: [VOTE] Theory based development > > > > > > One of my first tasks on joining the Apache River project was to > > > implement support for Java 5 language features in ClassDep . I don't > > > recall who requested Java 5 language feature support, however this > > > seemed like a good place to start, based on an initial contribution > > > from Tim Blackmann. The ClassDep api remained the same, however the > > > underlying implementation was completely rewritten. > > > > > > This work has been included in all releases of Apache River since I > > > joined and I'm yet to hear one complaint, without it, the transition > > > to Java 5 may have been quite different. > > > > > > Moving on to our current circumstance, most of River's code pre dates > > > the Java Memory Model released with Java 5, it would be unreasonable > > > to expect code pre dating a standard to be compliant with it. > > > > > > My attempts to fix random intermittent test failures, unrelated to > > > code changes, but affected by timing, has lead to a cascading series > > > of failures, every time I fixed a problem a new problem would appear. > > > > > > FindBugs no longer reports many multi-threaded issues in release code > > > (FindBugs isn't instrumented to analyse classes that use > > > ReadersWriter), although quite a few remain in the test suite. > > > > > > I believe the majority of multi threaded issues are fixed, with some > > > remaining hold outs based on TaskManager.Task.runAfter() and other > > > remaining in the test suite. > > > > > > The major problem that faces my development now however is not multi > > > threaded bugs, instead it is the River development community > > > remaining undecided on supporting or not supporting Theory based > > > development. > > > > > > My reasoning is this: > > > > > > 1. > > > > > > To ameliorate issues reviewing change raised by other developers, > > > I plan to document my changes on Jira (this will be a huge effort > > > that will take months). > > > > > > 2. > > > > > > Many of these issues are based on theory and analysis, many > > > examples will be fields accessed from multiple threads without > > > synchronisation, but there will be no test cases exposing bugs > > > (most concurrency bugs are not repeatable). > > > > > > 3. > > > > > > My recent attempt to create an interface Startable, met with much > > > controversy. I'm sure that if I had supplied a test case > > > demonstrating a failure there would be no argument, however > > > because my analysis was based on theory, the alternative solution > > > posed was things were acceptable the way they were and that object > > > construction would be complete before other threads could see the > > > reference (without any evidence to prove otherwise either). > > > > > > 4. > > > > > > There is a significant risk, with theoretical based issues raised > > > on Jira, that the status quo will prevail and my efforts wasted. > > > > > > > > > The right thing to do is at least tell me, as your fellow developer, > > > whether the community supports theory based development or not, to > > > save me wasting time fixing any more bugs or documenting them, (if > > > that is the case) and to allow me to focus on something the > > > community does > > support. > > > > > > If the community does support theory based development, then I > > > suggest we pose the issue of publishing an object with final fields > > > where other threads can see it, prior to its constructor completing > > > to the concurrency interest list and see what the experts thoughts > > > are, then I'd propose we also use this approach with other issues, > > > by consulting experts in each field relating to a bug? > > > > > > Do you support theory based development? > > > > > > +1 Peter Firmstone. > > > > > > > > > > > > >
