RE: [VOTE] Theory based development
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. > > >
Re: [VOTE] Theory based development
I am a remote expectator, but +1. Thanks for all the effort. On Sun, Jan 19, 2014 at 2:50 AM, Bishnu Gautam 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. > > > > > > > >
Re: [VOTE] Theory based development
Thank you Luis & Bishnu for your support. For others who might be undecided, the intent of this vote is to establish rules to judge theoretical changes by, not to approve specific changes. So why are we having this vote? Concurrency problems are very hard to generate reliable test cases for, when we find code that breaks simple rules set out in "Concurrency in practise", the Java memory model, or an expert interpretation of the JMM (eg concurrency interest mail list), we want to be able to fix it. To date, attempts to discuss fixing these bugs have been contraversial, despite proposed fixes not breaking backward compatibility. Alternative arguments have not been for alternate fixes, but maintaining the status quo, based on arguments around providing solid experimental evidence of failure. The intent of theoretical analysis based bug fixes is to maintain backward compatibility and improve stability by removing the possibility of race conditions. The goal of this vote is to remove contraversy in decisions about and provide centainty for bug fixes, so we can get on with development. This vote is not a vote for the bug fixes themselves. I'd also like to encourage the wider community to get involved, share your thoughts and votes, for or against. The outcome, whatever it may be, will provide certainty. Thanks & regards, Peter Firmstone. - Original message - > I am a remote expectator, but +1. > Thanks for all the effort. > > > On Sun, Jan 19, 2014 at 2:50 AM, Bishnu Gautam > 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
[DISCUSS] Was: Re: [VOTE] Theory based development
On Jan 18, 2014, at 10:45 PM, Peter Firmstone wrote: > > > 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. > > You are mistaken in this statement, at least from my viewpoint. This idea of “Theory-based development” is a complete red herring. Speaking for myself, what concerns me is sweeping changes to code that has already been released. Especially when those changes are followed by a cascade of further failures, which then causes more sweeping, un-discussed changes. I want you to involve the community (including listening to us) in discussing the risks and benefits of making those changes, and developing a strategy to minimize the risks. Ultimately I think we need to extend our “review-then-commit” policy from API to the complete released codebase. Granted, qa_refactor is an experimental branch. So eventually the community needs to figure out how to move forward with experimental branches when they deviate significantly from the released branches. Cheers, Greg.
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
Greg, We need to define the terms of reference for our discussion of proposed changes. We need to avoid emotive arguments, like “complete red herring”, “cascade of further failures” and “sweeping changes”. I believe a much greater risk is not fixing issues, I believe I can demonstrate that, given the opportunity. I also encourage all who are interested to become involved. Which is why I’m asking you to vote on theory driven development: Just before Christmas, you were discussing whether to fix concurrency problems based on theoretical analysis, or to only fix those problems for which there is experimental evidence. I believe the PMC will be at cross-purposes until you resolve that issue, and strongly advise discussing and voting on it. This is an example of a question whose answer would be obvious and non-controversial if you had agreement, either way, on that general issue. "When do you claim that this happens? And what currently happens now that is unacceptable? What is the concrete, observable problem that you’re trying to solve, that justifies introducing failures that require further work?" is a valid, and important, set of questions if you are only going to fix concurrency bugs for which there is experimental evidence. It is irrelevant if you are going to fix concurrency bugs based on theoretical analysis. Patricia If there are other practises you believe we should adopt, then you need to put forward a case for voting on them, preferably after this vote completes. Regards, Peter Firmstone. On 20/01/2014 1:22 AM, Greg Trasuk wrote: On Jan 18, 2014, at 10:45 PM, Peter Firmstone wrote: 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. You are mistaken in this statement, at least from my viewpoint. This idea of “Theory-based development” is a complete red herring. Speaking for myself, what concerns me is sweeping changes to code that has already been released. Especially when those changes are followed by a cascade of further failures, which then causes more sweeping, un-discussed changes. I want you to involve the community (including listening to us) in discussing the risks and benefits of making those changes, and developing a strategy to minimize the risks. Ultimately I think we need to extend our “review-then-commit” policy from API to the complete released codebase. Granted, qa_refactor is an experimental branch. So eventually the community needs to figure out how to move forward with experimental branches when they deviate significantly from the released branches. Cheers, Greg.
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
On Jan 20, 2014, at 3:00 AM, Peter Firmstone wrote: > Greg, > > We need to define the terms of reference for our discussion of proposed > changes. We need to avoid emotive arguments, like “complete red herring”, > “cascade of further failures” and “sweeping changes”. I believe a much > greater risk is not fixing issues, I believe I can demonstrate that, given > the opportunity. I also encourage all who are interested to become involved. > > Which is why I’m asking you to vote on theory driven development: I will abstain from this vote. Cheers, Greg.
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
Given the number of users on this mailing list, and the tiny number of votes, it seems that many people are abstaining. Why is this such a touchy issue? -- Dawid Loubser Op Ma, 2014-01-20 om 09:25 -0500 skryf Greg Trasuk: > On Jan 20, 2014, at 3:00 AM, Peter Firmstone wrote: > > > Greg, > > > > We need to define the terms of reference for our discussion of proposed > > changes. We need to avoid emotive arguments, like “complete red herring”, > > “cascade of further failures” and “sweeping changes”. I believe a much > > greater risk is not fixing issues, I believe I can demonstrate that, given > > the opportunity. I also encourage all who are interested to become > > involved. > > > > Which is why I’m asking you to vote on theory driven development: > > I will abstain from this vote. > > Cheers, > > Greg. > signature.asc Description: This is a digitally signed message part
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
I can only give you my own thoughts and experiences, others may think differently. The current codebase was created through an experimental development process by Sun, it hadn't been compiled and tested on Java 5 until River took ownership. The code's now a tad on the brittle side, fixing something simple, often reveals unrelated latent bugs. A change in JDK version is also doing exactly that right now, see our windows 2008 JDK7 Jenkins build, 45 test failures. - Don't deploy on Java 7 yet is my advise. To change the codebase to a more theory driven design, means fixing code that works good enough, which also causes latent bugs to manifest. Making such a transition means fixing a lot of non compliant code, or releasing with some failing tests and risk latent bugs manifesting during deployment. Out of interest, Porter (Jini 2.1) was released with some tests disabled, including a stress test for Outrigger, StressTestInterleaved, that test now passes on qa_refactor. The benefit of these changes is more robust easier to maintain and develop code. The risk is we might unintentionally break something. This is one of those cases, where it's easy to criticise, but hard to do. The River community has spoken with their silence on this occassion. Unless some discussion indicates otherwise, I intend to let the River community decide when it's ready to integrate fixes from qa_refactor and will no longer be looking to merge and release. For that reason, I also reccommend reverting trunk, with the exception of Sim's recent work, which I have peer reviewed. Regards, Peter. - Original message - > Given the number of users on this mailing list, and the tiny number of > votes, it seems that many people are abstaining. > Why is this such a touchy issue? > > -- > Dawid Loubser > > > Op Ma, 2014-01-20 om 09:25 -0500 skryf Greg Trasuk: > > > On Jan 20, 2014, at 3:00 AM, Peter Firmstone wrote: > > > > > Greg, > > > > > > We need to define the terms of reference for our discussion of > > > proposed changes. We need to avoid emotive arguments, like > > > “complete red herring”, “cascade of further failures” and “sweeping > > > changes”. I believe a much greater risk is not fixing issues, I > > > believe I can demonstrate that, given the opportunity. I also > > > encourage all who are interested to become involved. > > > > > > Which is why I’m asking you to vote on theory driven development: > > > > I will abstain from this vote. > > > > Cheers, > > > > Greg. > > >
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
Peter,
I've been silent for a bit (lots going on for me), but suffice it to say I
don't have any issue with you going after the many issues (synchronization
based and other) that River has. For goodness sake, we're dealing with a
codebase that is 1.4 based and has many issues, you've uncovered many of them.
I just took a quick look at OutriggerServerImpl, and saw this:
1701: public long renew(Uuid cookie, long extension)
1702: throws UnknownLeaseException, LeaseDeniedException
1703: {
1704: leaseLogger.entering("OutriggerServerImpl","renew");
1705:
1706: LeasedResourceresource;
1707: LeasePeriodPolicy policy;
1708:
1709: if (null != (resource = contents.getLeasedResource(cookie)))
1710: policy = entryLeasePolicy;
1711: else if (null !=
1712:(resource = (LeasedResource)eventRegistrations.get(cookie)))
1713: policy = eventLeasePolicy;
1714: else if (null !=
1715:(resource = (LeasedResource)contentsQueries.get(cookie)))
1716: policy = contentsLeasePolicy;
1717: else
1718: throw throwNewUnknownLeaseException(cookie);
1719:
1720: synchronized (resource) {
...
}
How is that exactly supposed to work? There are many cases just like this in
the codebase that need to be addressed.
Not to mention getting River up to Java 7 (at least). There is no support for
generics (I see you've at least changed Configuration to support so casting is
not required (thank god)). There are so many idioms of modern Java development
are simply not even close to being available.
So a suggestion; maybe we have the legacy branch (2.2) maintained, and River
3.0 moved forward and created from the qa_refactor branch. The new River 3.0
includes the repackaging of com.sun.jini to org.apache.river, includes the work
you've been doing (we need to at least have a list of the changes). Seems like
a nice break. Also, if the tests pass, whats the issue with the work thats been
done in qa_refactor?
BTW, I'm not particularly sold on Startable, because the interface does not
guarantee anything. A service implementation can still call start() in it's
constructor and all of the intentions of the interface are moot. Unless a
service's lifecycle can be controlled by an invoking class, you have no
guarantees.
Regards
Dennis
On Jan 21, 2014, at 840PM, Peter wrote:
> I can only give you my own thoughts and experiences, others may think
> differently.
>
> The current codebase was created through an experimental development process
> by Sun, it hadn't been compiled and tested on Java 5 until River took
> ownership. The code's now a tad on the brittle side, fixing something
> simple, often reveals unrelated latent bugs. A change in JDK version is also
> doing exactly that right now, see our windows 2008 JDK7 Jenkins build, 45
> test failures. - Don't deploy on Java 7 yet is my advise.
>
> To change the codebase to a more theory driven design, means fixing code that
> works good enough, which also causes latent bugs to manifest.
>
> Making such a transition means fixing a lot of non compliant code, or
> releasing with some failing tests and risk latent bugs manifesting during
> deployment. Out of interest, Porter (Jini 2.1) was released with some tests
> disabled, including a stress test for Outrigger, StressTestInterleaved, that
> test now passes on qa_refactor.
>
> The benefit of these changes is more robust easier to maintain and develop
> code.
>
> The risk is we might unintentionally break something.
>
> This is one of those cases, where it's easy to criticise, but hard to do.
>
> The River community has spoken with their silence on this occassion.
>
> Unless some discussion indicates otherwise, I intend to let the River
> community decide when it's ready to integrate fixes from qa_refactor and will
> no longer be looking to merge and release.
>
> For that reason, I also reccommend reverting trunk, with the exception of
> Sim's recent work, which I have peer reviewed.
>
> Regards,
>
> Peter.
>
>
> - Original message -
>> Given the number of users on this mailing list, and the tiny number of
>> votes, it seems that many people are abstaining.
>> Why is this such a touchy issue?
>>
>> --
>> Dawid Loubser
>>
>>
>> Op Ma, 2014-01-20 om 09:25 -0500 skryf Greg Trasuk:
>>
>>> On Jan 20, 2014, at 3:00 AM, Peter Firmstone wrote:
>>>
Greg,
We need to define the terms of reference for our discussion of
proposed changes. We need to avoid emotive arguments, like
“complete red herring”, “cascade of further failures” and “sweeping
changes”. I believe a much greater risk is not fixing issues, I
believe I can demonstrate that, given the opportunity. I also
encourage all who are interested to become involved.
Which is why I’m asking you to vote on theory driven development:
>>>
>>> I will abstain from this vote.
>>>
>>> Cheers,
>>>
>>> Greg.
>>>
>>
>
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
Startable only had one purpose:
To provide the implementor a thread of execution after construction completes.
It's provided by the the infrastructure to the service implementation, what the
implementor does with it is their business.
One alternative was, for our service implementations to be moved to abstract
classes and threads started and exporting performed in stateless concrete
classes, the other was to removal all final field modifiers, Startable was
simple and seemed more elegant.
That's about it in a nutshell, sorry if you got the impression it had another
purpose.
The problem with the tests; they've had bug fixes too, so people have trouble
trusting them.
The section of code you've found in Outrigger is ugly but correct, ideally sync
would be the responsibility of resource but in this case it's external.
Peter.
- Original message -
> Peter,
>
> I've been silent for a bit (lots going on for me), but suffice it to say
> I don't have any issue with you going after the many issues
> (synchronization based and other) that River has. For goodness sake,
> we're dealing with a codebase that is 1.4 based and has many issues,
> you've uncovered many of them.
>
> I just took a quick look at OutriggerServerImpl, and saw this:
>
> 1701: public long renew(Uuid cookie, long extension)
> 1702: throws UnknownLeaseException, LeaseDeniedException
> 1703: {
> 1704: leaseLogger.entering("OutriggerServerImpl","renew");
> 1705:
> 1706: LeasedResource resource;
> 1707: LeasePeriodPolicy policy;
> 1708:
> 1709: if (null != (resource = contents.getLeasedResource(cookie)))
> 1710: policy = entryLeasePolicy;
> 1711: else if (null !=
> 1712: (resource = (LeasedResource)eventRegistrations.get(cookie)))
> 1713: policy = eventLeasePolicy;
> 1714: else if (null !=
> 1715: (resource = (LeasedResource)contentsQueries.get(cookie)))
> 1716: policy = contentsLeasePolicy;
> 1717: else
> 1718: throw throwNewUnknownLeaseException(cookie);
> 1719:
> 1720: synchronized (resource) {
>
> ...
> }
>
> How is that exactly supposed to work? There are many cases just like
> this in the codebase that need to be addressed.
>
> Not to mention getting River up to Java 7 (at least). There is no
> support for generics (I see you've at least changed Configuration to
> support so casting is not required (thank god)). There are so many
> idioms of modern Java development are simply not even close to being
> available.
>
> So a suggestion; maybe we have the legacy branch (2.2) maintained, and
> River 3.0 moved forward and created from the qa_refactor branch. The new
> River 3.0 includes the repackaging of com.sun.jini to org.apache.river,
> includes the work you've been doing (we need to at least have a list of
> the changes). Seems like a nice break. Also, if the tests pass, whats
> the issue with the work thats been done in qa_refactor?
>
> BTW, I'm not particularly sold on Startable, because the interface does
> not guarantee anything. A service implementation can still call start()
> in it's constructor and all of the intentions of the interface are moot.
> Unless a service's lifecycle can be controlled by an invoking class, you
> have no guarantees.
>
> Regards
>
> Dennis
>
> On Jan 21, 2014, at 840PM, Peter wrote:
>
> > I can only give you my own thoughts and experiences, others may think
> > differently.
> >
> > The current codebase was created through an experimental development
> > process by Sun, it hadn't been compiled and tested on Java 5 until
> > River took ownership. The code's now a tad on the brittle side,
> > fixing something simple, often reveals unrelated latent bugs. A
> > change in JDK version is also doing exactly that right now, see our
> > windows 2008 JDK7 Jenkins build, 45 test failures. - Don't deploy on
> > Java 7 yet is my advise.
> >
> > To change the codebase to a more theory driven design, means fixing
> > code that works good enough, which also causes latent bugs to manifest.
> >
> > Making such a transition means fixing a lot of non compliant code, or
> > releasing with some failing tests and risk latent bugs manifesting
> > during deployment. Out of interest, Porter (Jini 2.1) was released
> > with some tests disabled, including a stress test for Outrigger,
> > StressTestInterleaved, that test now passes on qa_refactor.
> >
> > The benefit of these changes is more robust easier to maintain and
> > develop code.
> >
> > The risk is we might unintentionally break something.
> >
> > This is one of those cases, where it's easy to criticise, but hard to
> > do.
> >
> > The River community has spoken with their silence on this occassion.
> >
> > Unless some discussion indicates otherwise, I intend to let the River
> > community decide when it's ready to integrate fixes from qa_refactor
> > and will no longer be looking to merge and release.
> >
> > For that reason, I also reccommend reverting trunk, with the exception
> >
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
On Jan 22, 2014, at 657AM, Peter wrote: > Startable only had one purpose: > > To provide the implementor a thread of execution after construction completes. > > It's provided by the the infrastructure to the service implementation, what > the implementor does with it is their business. By itself it's harmless, but the point being here is that the Startable interface semantics cannot enforce the problem you are trying to solve. > > One alternative was, for our service implementations to be moved to abstract > classes and threads started and exporting performed in stateless concrete > classes, the other was to removal all final field modifiers, Startable was > simple and seemed more elegant. > > That's about it in a nutshell, sorry if you got the impression it had another > purpose. > > The problem with the tests; they've had bug fixes too, so people have trouble > trusting them. > > The section of code you've found in Outrigger is ugly but correct, ideally > sync would be the responsibility of resource but in this case it's external. Synchronizing on local variables is usually a bad idea. If the object that resource points to will *always* be the same, then the synchronized(resource) block does in fact use that quasi-global object's monitor. IMO it would be a better practice to use a synchronized wrapper here. Dennis
Re: [DISCUSS] Was: Re: [VOTE] Theory based development
I was more thinking along the lines of encouraging best practise. Right now, if you read River's service implementations, every single one uses final fields and publishes partially constructed service reference to other threads, the hotspot compiller is free to reorder so these, so threads see partially constructed objects and default values for final fields. The reference shared during export is never updated, so threads carrying method invocations from remote clients never see a safely published reference and there is no way to obtain one at present. If people want it enforced, I could create a private class, that extends SecurityManager, walks the call stack, checks if export is being performed during construction, then use reflection to check for final fields and throw an exception if it does, but that doesn't ensure the service is thread safe. Presently we expect service implementations to be thread safe (remote method invocation is performed via a thread pool), but River doesn't provide an easy way for implementors to use final fields. Services can also use static methods and writeReplace, provided they're not using the starter kit. Peter. - Original message - > > On Jan 22, 2014, at 657AM, Peter wrote: > > > Startable only had one purpose: > > > > To provide the implementor a thread of execution after construction > > completes. > > > > It's provided by the the infrastructure to the service implementation, > > what the implementor does with it is their business. > > By itself it's harmless, but the point being here is that the Startable > interface semantics cannot enforce the problem you are trying to solve. > > > > > One alternative was, for our service implementations to be moved to > > abstract classes and threads started and exporting performed in > > stateless concrete classes, the other was to removal all final field > > modifiers, Startable was simple and seemed more elegant. > > > > That's about it in a nutshell, sorry if you got the impression it had > > another purpose. > > > > The problem with the tests; they've had bug fixes too, so people have > > trouble trusting them. > > > > The section of code you've found in Outrigger is ugly but correct, > > ideally sync would be the responsibility of resource but in this case > > it's external. > > Synchronizing on local variables is usually a bad idea. If the object > that resource points to will *always* be the same, then the > synchronized(resource) block does in fact use that quasi-global object's > monitor. IMO it would be a better practice to use a synchronized wrapper > here. > > > Dennis
