river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bishnu Gautam <bishn...@hotmail.com>
Subject RE: [VOTE] Theory based development
Date Sun, 19 Jan 2014 04:50:35 GMT

Hi Peter
I totally support theory based development.+1
RegardsBishnu


Bishnu Prasad Gautam


> Date: Sun, 19 Jan 2014 13:45:49 +1000
> From: jini@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.
> 
> 
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message