You have no objections to Theoretical analysis? Now you've had a chance to review the JMM, has it changed your thoughts on Startable?
Regards, Peter. ----- Original message ----- > > On Jan 4, 2014, at 6:15 PM, Peter <j...@zeus.net.au> wrote: > > > > > > > “we’re using final variables, therefore all our code has to change” > > > (paraphrasing) are no substitute for reasoned analysis. > > > > You don't agree that final field usage should comply with the JMM? > > > > Please also read the Java Memory Model. > > > > JMM is part of the JLS now. I read it. I read with particular interest > the parts about the many possibilities for when the values of final > variables are frozen. > > > > > > > I teach programming. I see this all the time. When people make > > > changes based on what they “think” “might” be happening, it’s always > > > a disaster. > > > > You're assuming FindBugs, JMM non-compliance and common issues > > described by Concurrency in Practise, when clearly and easily > > identified fall into the same category as someone who's learning to > > code for the first time? > > > > You're advocating a completely experimental driven approach, like > > someone who's learning to program experiences. It is very good > > approach for learning… > > > > Please don’t put words in my mouth. I’m not talking about experimental > vs theoretical. I’m talking about diagnostic techniques. You need to > have a theory about what a problem is, gather information to support or > disprove that theory (that could be either analysis or experiments), and > only then make changes to the code. Then gather information that proves > your fix actually made a difference (again, could be analysis or > experiments). > > > > > This would prevent a move from experimental to include a more > > theoretical development approach. Test cases are still required to > > pass with a theoretical approach. > > > > Not at all. “Findbugs reports a possible data race in TaskManager” is a > perfectly good JIRA issue that is specific enough to be actionable and > should be limited enough in scope that peers can review the solution. > > > and includes the community in decisions around how to fix > > > the problem that is stated. > > > > And when a simple discussion about a simple issue veers off topic with > > heated arguments, what then? You propose I stop committing to skunk, > > until each change is discussed at length on the list? But we can't > > even agree on final field usage? > > > > We need to make a decision whether to include theoretical driven > > development that includes compliance to standards like the JMM. > > > > As I’ve said before, my concern is not theoretical vs experimental. > It’s “what is this change, why was it made, what are the effects, and > are its effects justifiable?” > > > Code has been committed to skunk, for people to review, in public, > > they might misinterpret my suggestions on the mail list, but they will > > have a better understanding after reading the code, I welcome their > > participation. > > > > There are 1557 files modified between 2.2.2 and qa_refactor. 62 > deleted. 214 added. How practical is it to review? > > > I am open to other solutions, but I don't like the suggestion that non > > compliant code is preferred until a test case that proves failure can > > be found. What happens when the test case only fails on one platform, > > but is not easily repeatable? What if the fix just changes timing to > > mask the original problem? > > > > Testing doesn't prove the absence of errors? Reducing errors further > > requires additonal tools like FindBugs and public open peer review. > > > > Trunk development was halted because of unrelated test failures. > > It was halted because the community got nervous and started asking for > review-then-commit, so you moved over to qa_refactor. From 2.2.2 to > trunk - 1225 files modified, 32 deleted, 186 added. Same problem, which > we discussed last year. > > Related email threads: > > http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C50B49395.30408%40qcg.nl%3E > http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3CCAMPUXz9z%2Bk1XBgzfCONmRXh8y5yBtMjJNeUeTR03YEepe-60Zg%40mail.gmail.com%3E > > In the end, you’re right - qa_refactor is a skunk branch, so you can go > ahead and make all the changes you want. I just think that if your > intention is to get at least two other people to sign off on it as a > release, you’d do well to make it easy to review, and possibly even > include the community in the decision-making along the way. > > Regards, > > Greg. > > > >
