Java performance tuning

On the following page you will find many articles about java performance tuning. Tips, tools descriptions, ...
http://www.javaperformancetuning.com

Uncle Bob says

Last week I attended training Clean Code lead by Robert Martin known as Uncle Bob. He is a software professional since 1970, a consultant and an author of many bestsellers concerning software development e.g.

• Designing Object-Oriented C++ Applications using the Booch Method. Prentice-Hall. 1995. ISBN 0-13-203837-4.
• Agile Software Development: Principles, Patterns and Practices. Pearson Education. 2002. ISBN 0-13-597444-5.
• Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR. 2008. ISBN 0-13-235088-2.
• The Clean Coder: A Code of Conduct for Professional Programmers.

Here is my summary of the course:

• Software engineers' job is to write code. It is the document of the systems we provide.
• Our work is to do things well. Managers defend the schedule, but our job is to defend the code with equal passion. Quality needs time! They want the truth even if they don't like it.
• Architecture's aim is separation of relevant things from irrelevant ones.
• Yoda was right! Do or do not. There is no try. Decide. Don't lose time.
• The only good measure of clean code is the quantity of WTF per minute while working with this code.
• To keep in shape as a developer you have to practice. Have your programming Kata. Practice regularly solving programming problems. e.g. try developing sorting of an array.
• Always start coding by writing a test. TDD allows you to develop faster. Coverage of code written using TDD is nearly 100%! Maintenance of such code is easier and refactoring can be proven to be correct.
• As test gets more specific, the code gets more general. (Described here: http://cleancoder.posterous.com/the-transformation-priority-premise)
• Long live variables which are searchable should have long names, short live ones should have short names.
• Consider factors methods instead of constructors. Complex.FromRealNumber(23.4) oposed to new Complex(23.4). It is more readable.
• Use methods String.format. It will generate strings with correct end of lines. Just use %n as a line break.
• Don't use brackets if you don't need to.
• Write as small functions as possible. If some lines of function can be extracted as another function, do it. Three, four, five lines for a function is best. It will be more readable.
• Functions should do one thing.
• While refactoring, remember also to change variables' names to correspond with their usage.
• Name of the function can be long. It should describe its action. It is better than adding an additional comment.
• Short function names should be used for bigger scope (like File.open) whereas long function names should be used for small private scopes.
• Use convention for test methods: whenBuyOneBook. Your method will be like a sentence: When action, we assert results.
• Use as small arguments of the function as possible. More than a three are rarely justified.
• Avoid functions with side effects like the ones that change variables of their class, passed arguments or system globals.
• Prefer exceptions to returning error code.
• Extract try catch blocks into functions.
• Clean code doesn't need comments, or only residual ones. Usually we have them too many so IDE changes its color to grey by default. Change color of comments to red, so you will keep them simple, they will strike your eyes.
• Every use of comment represents a failure of expressing ourselves in code. Use comments as a last resort.
• When you write bad code, don't comment it. Clean it!
• Good comments: legal statements, allowed string patterns (like hh:mm:ss), description of intents.
• Avoid TODO comments. Most frequently they are left forever.
• Don't add author in comments. Control system is used for this.
• Don't add html in the comments. It will be harder to read where it is read, I mean in code. If you need it for javadoc then use pre tag.
• Decouple code into many files. Too long files are wrong.
• Keep related variables and functions close to each other
• We prefer 25-40 chars line lengths.
• Team should agree on the formatting rules. Code should look like written by the team not a group of individuals.

Android Lint - Firebugs for Android applications

Android Lint is a new tool introduced in ADT 16 (and Tools 16) which scans Android project sources for potential bugs. It is available both as a command line tool, as well as integrated with Eclipse. The architecture is deliberately IDE independent so it will hopefully be integrated with other IDEs, with other build tools and with continuous integration systems as well.
http://tools.android.com/tips/lint

Synchronized block

In java we can add keyword synchronized on the method definition to allow only one thread to execute all object's methods with synchronized at once.
So it looks like this:

  synchronized void add() {
    // some code
  }

It is the same as:

  void add() {
    synchronized(this){
      // some code
    }
  }

When we want to synchronize on the static method we can synchronize on the class object:

  static void add() {
    synchronized(MyClass.class){
      // some code
    }
  }

But it is much more secure to synchronize on the static private object. So only our object can use this lock. On the class object which is public any thread from any piece of code could do it.
So better use this lock:

  private static final Object lock = new Object(); 

  static void add() {
    synchronized(lock){
      // some code
    }
  }

Lazy initialization in java

Lazy initialization in java can be done in different ways.

• In java we can use keyword volatile. This attribute on variable guarantees that any thread will see the most recently written value. From Java 5 version it can be used f.e. for lazy initialization in a multi-threaded environment.
• Another way to do this is to use inner classes. This relies on the fact that inner classes are not loaded until they are referenced. So we can make assignment in the inner class.
• We can also use synchronized block, but it is estimated to be 100 times slower then using volatile variable.

You can see more examples here: http://en.wikipedia.org/wiki/Double-checked_locking

GEB - browser automation solution

Geb is a browser automation solution.
It brings together the power of WebDriver, the elegance of jQuery content selection, the robustness of Page Object modelling and the expressiveness of the Groovy language.
Read more on the project home page: http://www.gebish.org/

RemoteWebDriver

You can test UI automation tests with WebDriver for browsers that are not installed on your machine. Use RemoteWebDriver.
Read more on: http://code.google.com/p/selenium/wiki/RemoteWebDriverServer