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>
