river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject [VOTE] Theory based development
Date Sun, 19 Jan 2014 03:45:49 GMT
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:


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


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


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


      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.

View raw message