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<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > Matt Sicker <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
