I'm not sure where I stand with regards to votes and what-not anymore, but here's my opinion. I think it's wise to do a quick release with the minimum of changes in Right Now. Particularly if those changes includes the JDK7 fix. Releasing as many changes as there are without more consideration just feels too risky. The greater need right now is to get the bare minimum release out asap to fix some real-life issues.
That's not a comment on what I think the quality of all the trunk changes are, it's just my gut feel. To counter some of Greg's comments, if we trusted the old tests for previous releases, then digging our way out of the hole is not hugely difficult. We just run the old tests against the new code to verify the new code. Then we run the new tests against an old release. There will be some additional due diligence needed to tie up loose ends and un-grey some areas, but I think we can then have a good degree of confidence in both the new tests and new code. When that's done, I would suggest that it sounds like another release would be due. Then the source tree can be straightened out with the right bits merged to the right branches and the right branches being created for the right work streams. I don't think that there is much value in debating the motives people have had for the code they've written/changed. As has been said before, we've all got our own itches to scratch. If there is a technical reason for blocking some change then fine, but I don't believe that a lack of benchmarks detailing some pain point is a reason to throw it out. Questioning the Why is often useful because it can aid a discussion and guide us to what the real What should be, but I'm not sure that it will in the case - then again, I've been wrong before... So I think that it is a good approach to modify the code so it follows the advice given in what many would consider the "Concurrency Bible" - even if I can't prove that the previous implementation was flawed in some way. Dan has mentioned the policy (or lack of) with regards to what gets put onto trunk and that is something that should really be discussed. So some questions; - Is there a policy? - Was it the right policy? - Did we stick to the policy? - What is a better policy? Then everything else from Maven, to separate builds, to TaskManager replacements (or not), to whatever else should just slot into place. Lastly, I'm glad that the conversation has calmed down. Thanks to both Greg for not biting and Peter for responding in kind. Your reactions to what could have become a nasty situation speaks volumes to both of your characters and that's A Good Thing. Cheers, Tom On Mon, Apr 8, 2013 at 2:42 PM, Dan Creswell <dan.cresw...@gmail.com> wrote: > > This is an important issue to address. I know a lot of people here > >> probably don't participate on the Concurrency-interest mailing list that > >> has a wide range of discussion about the JLS vs the JMM and what the JIT > >> compilers actually do to code these days. > >> > > ... > > > > I used to be a concurrency expert, but have not been following the topic > > recently. For practical Java coding, I have tended to follow the ideas > > in Java Concurrency in Practice. Do any of the changes invalidate that > > approach? > > > > > No, they don't. The JMM hasn't really changed since the work Doug Lea did > for Java 5 and beyond. What has changed over time is the amount typical > JITs exploit the opportunities presented by the JMM for aggressive > instruction re-ordering etc. > > If your code "does the right things" it'll be fine. It just potentially > runs better (it could actually run worse in some cases). If you've > misunderstood JMM or how it relates to JLS then you may have problems. >
