Why are they not appropriate lock objects? Start a discussion before just changing them.
Ralph On Apr 28, 2014, at 10:40 AM, Matt Sicker <boa...@gmail.com> wrote: > In that case, Item 69: prefer concurrency utilities to wait and notify. > Sounds like we can just use a plain Object instance to lock (which is pretty > much equivalent to using ReentrantLock) when doing normal locks, but instead > of using .notifyAll() and .wait(), we should use the Condition interface > (which would require using Lock as well). > > I agree that using synchronized(object) makes sense when it's all that's > being done. However, I've been changing instances of synchronized(this) and > synchronized(foo) where foo is not an appropriate lock object (e.g., a > string, or a non-final object, things like that). > > > On 28 April 2014 12:28, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Yes, guidelines called out by Effective Java are appropriate when they apply. > > As for concurrency, “New” isn’t always better than old. In a few places you > changed synchronized(object) to use a Lock instead. There is little to no > value in doing that and makes the code look a little more cluttered. > However, if a ReadWriteLock can be used in place of synchronized that is a > real benefit. > > The point of the guidelines are that when it comes to stuff like this, unless > there is a guideline written down that says the current code is wrong discuss > it on the list before making a change. > > Ralph > > On Apr 28, 2014, at 9:35 AM, Matt Sicker <boa...@gmail.com> wrote: > >> What about style things covered by Effective Java? These are pretty much all >> good ideas. >> >> Also, how about some guidelines on concurrency? I'd recommend not using the >> old concurrency stuff and instead using java.util.concurrent.* for more >> effective concurrency. This doesn't include the Thread vs Runnable thing, so >> that's still debatable. >> >> >> On 28 April 2014 08:46, Gary Gregory <garydgreg...@gmail.com> wrote: >> Perhaps if one breaks the build, it should be polite to revert that last >> commit... >> >> Gary >> >> >> On Mon, Apr 28, 2014 at 3:07 AM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> I think we need to develop and post some development “guidelines”, “best >> practices” or whatever you want to call it for Log4j 2. Here are some of >> the things I would definitely want on it. >> >> 1. Error on the side of caution. If you don’t understand it, don’t touch it >> and ask on the list. If you think you understand it read it again or ask >> until you are sure you do. Nobody will blame you for asking questions. >> 2. Don’t break the build - if there is the slightest chance the change you >> are making could cause unit test failures, run all unit tests. Better yet, >> get in the habit of always running the unit tests before doing the commit. >> 3. If the build breaks and you have made recent changes then assume you >> broke it and try to fix it. Although it might not have been something you >> did it will make others feel a lot better than having to fix the mistake for >> you. Everyone makes mistakes. Taking responsibility for them is a good thing. >> 4. Don’t change things to match your personal preference - the project has >> style guidelines that are validated with checkstyle, PMD, and other tools. >> If you aren’t fixing a bug, fixing a problem identified by the tools, or >> fixing something specifically called out in these guidelines then start a >> discussion to see if the change is something the project wants before >> starting to work on it. We try to discuss things first and then implement >> the consensus reached in the discussion. >> >> Of course, the actual coding conventions we follow should also be spelled >> out, such as indentation, braces style, import ordering and where to use the >> final keyword. >> >> Ralph >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> JUnit in Action, Second Edition >> Spring Batch in Action >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> > > > > > -- > Matt Sicker <boa...@gmail.com>
