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