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