river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luis Matta <levma...@uol.com.br>
Subject Re: [VOTE] Theory based development
Date Sun, 19 Jan 2014 11:44:06 GMT
I am a remote expectator, but +1.
Thanks for all the effort.


On Sun, Jan 19, 2014 at 2:50 AM, Bishnu Gautam <bishnu35@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: 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