Best Practices for Coding - Java

Hi all,

After a while without publish anything, due family growing and moving to other country once again, I'm back now publishing some tips for better code, maintainability and some that will help you keep your memory usage footprint low. Of course if the project has a not very optimal architecture will be  hard just with code keep low memory footprint, though good code always helps.
This one is long, I have read articles from Oracle, across the web and the Java Performance Book (Link for Amazon Book) that I recommend and it's a really good book for those that want to have better performance with Java.
In this post, nearly all tips and good practices are for code, I hope this helps those one looking for improve their code or trying to set a bar for the minimum acceptable code quality.

Things to avoid at all cost in code, this is a basic thing and it’s an issue in most projects.

As the very first thing I would like to say to the developer to do is don’t be lazy in create object, variables or any other reference names, don’t make economy, use names that explain for any person what that reference.variable name really means, don’t expect that others guess what you were thinking earlier, not even make the mistake to think that you will remember exactly what the short naming mean after a couple of months doing something else in the project, be clear and verbose in explain a declaration.

E.g.:

// Don’t

public class BfProcCustAss {…

Object custAssActTdy = getCustomer();

// Do

public class BackfileProccessForCustmerAssociated {…

Object customerAssociatedActiveToday = getCustomer();

Avoid duplicated strings in the code as it is bad for code maintenance and memory, producing fragmented memory.

// Don’t – here you have two objects without any variable or instance variable association

If (customerType.equals(“Active”)) {

                foo.callCustomer(“Active”);

….

}

// Do – here you have one String object and two references to it

private static final String ACTIVE = “Active”;

// or

private final String ACTIVE = “Active”;

….

If (customerType.equals(ACTIVE)) {

                foo.callCustomer(ACTIVE);

….

}

NO, magical numbers please!

Try avoid those numbers that make so much sense to you at the code conception time though after a while not even you will be able to understand what it means.

E.g.:

final List<Object> myDifferentObjectList = getHeterogeneousObjectList();

…

// Don’t

BeanOne beanOne = myDifferentObjectList.get(5);

// Do

// Declare it in your method as var or as instance variable in your class

Private static final int BEAN_ONE = 5;

// Then

BeanOne beanOne = myDifferentObjectList.get(BEAN_ONE);

Or

// Don’t

cs.setString(2, feedToLookUp);

cs.setString(3, feedType);

cs.registerOutParameter(4, OracleTypes.CURSOR); // What are you getting from here?

cs.registerOutParameter(5, OracleTypes.VARCHAR); // and here?

// Do

final int PI_FEED_LOOK_UP = 2;

final int PI_FEED_TYPE = 3;

final int PO_RC_FEED_LIST = 4;

final int PO_MESSAGE_GROUP_ID = 5;

cs.setString(PI_FEED_LOOK_UP, feedToLookUp);

cs.setString(PI_FEED_TYPE, feedType);

cs.registerOutParameter(PO_RC_FEED_LIST, OracleTypes.CURSOR);  // Easier no?

cs.registerOutParameter(PO_MESSAGE_GROUP_ID, OracleTypes.VARCHAR);

Those tips above should be used with any language, not been restricted to Java, it’s a minimum for provide some code insight to the next developer that will maintain the code made by you.

The tips bellow are good for C++ and Java, however a few will be Java only as C++ has a quite better set for work with Threads than Java does, even today with the new Fork and Join released in JDK 7.

Avoid or Minimize Synchronization

Many performance studies have shown a high performance cost in using synchronization in Java. Improper synchronization can also cause a deadlock, which can result in complete loss of service because the system usually has to be shut down and restarted. But performance overhead cost is not a sufficient reason to avoid synchronization completely. Failing to make sure your application is thread-safe in a multi-threaded environment can cause data corruption, which can be much worse than losing performance. The following are some practices that you can consider to minimize the overhead:

Synchronize Critical Sections Only

Do Not Use the Same Lock on Objects That Are Not Manipulated Together

Use Private Fields

Use a Thread Safe Wrapper

Use Immutable Objects

Know Which Java Objects Already Have Synchronization Built-in

Do Not Under-Synchronize

Synchronize Critical Sections Only

If only certain operations in the method must be synchronized, use a synchronized block with a mutex instead of synchronizing the entire method. For example:

private Object mutex = new Object();

    ...

    private void doSomething()

    {

     // perform tasks that do not require synchronicity

        ...

        synchronized (mutex)

            {

            ...

            }

        ...

    }

Do Not Use the Same Lock on Objects That Are Not Manipulated Together

Every Java object has a single lock associated with it. If unrelated operations within the class are forced to share the same lock, then they have to wait for the lock and must be executed one at a time. In this case, define a different mutex for each unrelated operation that requires synchronization.

Also, do not use the same lock to restrict access to objects that will never be shared by multiple threads. For example, using Hashtables to store objects that will never be accessed concurrently causes unnecessary synchronization overhead:

public class myClass

{

    private static myObject1 myObj1;

    private static mutex1 = new Object();

    private static myObject2 myObj2;

    private static mutex2 = new Object();

    ...

    public static void updateObject1()

        {

            synchronized(mutex1)

            {

            // update myObj1 ...

            }

        }

    public static void updateObject2()

    {

                                synchronized(mutex2)

        {

        // update myObj2 ...

        }

    }

...

}

Use Private Fields

Making fields private protects them from unsynchronized access. Controlling their access means these fields need to be synchronized only in the class's critical sections when they are being modified.

Use a Thread Safe Wrapper

Provide a thread-safe wrapper on objects that are not thread-safe. This is the approach used by the collection interfaces in JDK 1.2.

Use Immutable Objects

An immutable object is one whose state cannot be changed once it is created. Since there is no method that can change the state of any of the object's instance variables once the object is created, there is no need to synchronize on any of the object's methods.

This approach works well for objects, which are small and contain simple data types. The disadvantage is that whenever you need a modified object, a new object has to be created. This may result in creating a lot of small and short-lived objects that have to be garbage collected. One alternative when using an immutable object is to also create a mutable wrapper similar to the thread-safe wrapper.

An example is the String and StringBuffer class in Java. The String class is immutable while its companion class StringBuffer is not. This is part of the reason why many Java performance books recommend using StringBuffer instead of string concatenation.

Know Which Java Objects Already Have Synchronization Built-in

Some Java objects (such as Hashtable, Vector, and StringBuffer) already have synchronization built into many of their APIs. They may not require additional synchronization.

Do Not Under-Synchronize

Some Java variables and operations are not atomic. If these variables or operations can be used by multiple threads, you must use synchronization to prevent data corruption. For example: (i) Java types long and double are comprised of eight bytes; any access to these fields must be synchronized. (ii) Operations such as ++ and -- must be synchronized because they represent a read and a write, not an atomic operation.

Monitor Synchronization

Java synchronization can cause a deadlock. The best way to avoid this problem is to avoid the use of Java synchronization. One of the most common uses of synchronization is to implement pooling of serially reusable objects. Often, you can simply add a serially reusable object to an existing pooled object. For example, you can add Java Database Connectivity (JDBC) and Statement object to the instance variables of a single thread model servlet, or you can use the Oracle JDBC connection pool rather than implement your own synchronized pool of connections and statements.

If you must use synchronization, you should either avoid deadlock, or detect it and break it. Both strategies require code changes. So, neither can be completely effective because some system code uses synchronization and cannot be changed by the application.

To prevent deadlock, simply number the objects that you must lock, and ensure that clients lock objects in the same order.

Proprietary JVM extensions may be available to help spot deadlocks without having to instrument code, but there are no standard JVM facilities for detecting deadlock.

Monitor and Fix Resource Leaks

One way to fix resource leaks is straightforward - a periodic restart. It provides good protection against slow resource leaks. But it is also important to spot applications that are draining resources too quickly, so that any software bugs can be fixed. Leaks that prevent continuous server operation for at least 24 hours must be fixed in the application code, not by application restart.

Common programming mistakes are:

Not returning the resource to the pool (or not removing it from the pool) after handling an error.

Relying on the garbage collector to invoke finalize() and free resources. Never rely on the garbage collector to manage any resource other than memory.

Not discarding old object references which prevent recycling the memory occupied by the objects.

Monitoring resource usage should be a combination of code instrumentation and external monitoring utilities. With code instrumentation, calls to an application-provided interface, or calls to a system-provided interface like Oracle Dynamic Monitoring System (DMS), are inserted at key points in the application's resource usage lifecycle. Done correctly, this can give the most accurate picture of resource use. Unfortunately, the same programming errors that cause resource leaks are also likely to cause monitoring errors. That is, you may forget to release the resource, or forget to monitor the release of the resource.

Operating system commands like vmstat or ps in UNIX, provide process-level information such as the amount of memory allocated, the number and state of threads, or number of network connections. They can be used to detect a resource leak. Some commercially available development tools can also be used to find the leak.

In addition to compromising availability, resource leaks and overuse decrease performance.

Always Use a Finally Clause in Each Method to Cleanup

In Java, it is impossible to leave the try or catch blocks (even with a throw or return statement) without executing the finally block. If for any reason the instance variables cannot be cleaned, throw a catch-all exception that should cause the caller to discard its object reference to this now corrupt object. If, for any reason the static variables cannot be cleaned, throw an InternalError or equivalent that will ultimately result in restarting the now corrupt JVM.

Discard Objects That Throw Catch-All Exceptions

In many cases, these exceptions indicate that the internal state of the invoked object is corrupt, and that further invocations will also fail. Keep the object reference only if careful scrutiny of the exception shows it is benign, and further invocations on this object are likely to succeed.

Adopt a guilty unless proven innocent approach. For example, a SQLException thrown from an Oracle JDBC invocation could represent one of thousands of error conditions in the JDBC driver, the network, or the database server. Some of these errors (for example, subclass SQLWarning) are benign. Some SQLExceptions (for example, "ORA-3113: end of file on communication channel") definitely leave the JDBC object useless. Most SQLExceptions do not clearly specify what state the JDBC object is left in. The best approach is to enumerate the benign error codes that could occur frequently in your application and can definitely be retried, such as a unique key violation for user-supplied input data. If any other error code is found, discard the potentially corrupt object that threw the exception.

Discard all object references to the (potentially) corrupt object. Be sure to remove the corrupt object from all pools in order to prevent pools from being poisoned by corrupt objects. Do not invoke the corrupt object again - instantiate a brandnew object instead.

When you are sure that the corrupt objects have been discarded and that the catching object is not corrupt, throw a non-catch-all exception so that the caller does not discard this object.

Design Transactions Usage Correctly

Transactions should not span client requests because this can tie up shared resources indefinitely.

Requests generally should not span more than one transaction, because a failure in mid-request could leave some transactions committed and others rolled back. If this requires application-level compensation to recover, then availability or data integrity may be compromised.

Transactions generally should not span more than one database, because distributed transactions lock shared resources longer, and failure recovery may require simultaneous availability and coordination of multiple databases.

Applications that require a single client request (for example, a confirm checkout request in a shopping cart application) to ultimately affect several databases (for example, credit card, fulfillment, shopping cart, and customer history databases) should perform the first step with one database, and in the same transaction queue a message in the first database addressed to the second database. The second database will perform the second step and queue the third step, and so on. This queued transaction chain will eventually complete automatically, or an administrator will see an undeliverable message and will have to manually compensate.

Put Business Logic in the Right Place

In general, you should not implement business logic in your client program. Instead, put validation and defaulting logic in your entity objects, and put client-callable methods in application modules, view objects, and view rows.

Working with application module methods allows the client program to encapsulate task-level custom code in a place that allows data-intensive operations to be done completely in the middle-tier without burdening the client.

Working with view object methods allows the client program to access the entire row collection for cross-row calculations and operations.

Working with view row methods allows the client program to operate on individual rows of data. There are three types of custom view row methods you may want to create:

Accessor methods: The oracle.jbo.Row interface (which view rows implement) contains the methods getAttribute() and setAttribute(), but these methods are not typesafe. You can automatically generate custom typesafe accessors when you generate a custom view row class.

Delegators to entity methods: By design, clients cannot directly access entity objects. If you want to expose an entity method to the client tier, you should create a delegator method in a view row.

Entity-independent calculations: This is useful if the calculation uses attributes derived from multiple entity objects or from no entity objects.

Avoid Common Errors That Can Result In Memory Leaks

In Java, memory bugs often appear as performance problems, because memory leaks usually cause performance degradation. Because Java manages the memory automatically, developers do not control when and how garbage is collected. To avoid memory leaks, check your applications to make sure they:

Release JDBC ResultSet, Statement, or connection.

Release failures here are usually in error conditions. Use a finally block to make sure these objects are released appropriately.

Release instance or resource objects that are stored in static tables.

Perform clean up on serially reusable objects.

An example is appending error messages to a Vector defined in a serially reusable object. The application never cleaned the Vector before it was given to the next user. As the object was reused over and over again, error messages accumulated, causing a memory leak that was difficult to track down.

Avoid Creating Objects or Performing Operations That May Not Be Used

This mistake occurs most commonly in tracing or logging code that has a flag to turn the operation on or off during runtime. Some of this code goes to great lengths creating and formatting output without checking the flag first, creating many objects that are never used when the flag is off. This mistake can be quite expensive, because tracing and logging usually involves many String objects and operations to translate the message or even access to the database to retrieve the full text of the message. Large numbers of debug or trace statements in the code make matters worse.

Replace Hashtable and Vector With Hashmap, ArrayList, or LinkedList If Possible

The Hashtable and Vector classes in Java are very powerful, because they provide rich functions. Unfortunately, they can also be easily misused. Since these classes are heavily synchronized even for read operations, they can present some challenging problems in performance tuning. Hence, the recommendations are:

Use an Array Instead of an ArrayList If the Size Can Be Fixed

Use an ArrayList or LinkedList To Hold a List of Objects In a Particular Sequence

Use HashMap or TreeMap To Hold Associated Pairs of Objects

Replace Hashtable, Vector, and Stack

Avoid Using String As the Hash Key (If Using JDK Prior to 1.2.2)

Use an Array Instead of an ArrayList If the Size Can Be Fixed

If you can determine the number of elements, use an Array instead of an ArrayList, because it is much faster. An Array also provides type checking, so there is no need to cast the result when looking up an object.

Use an ArrayList or LinkedList To Hold a List of Objects In a Particular Sequence

A List holds a sequence of objects in a particular order based on some numerical indexes. It will be automatically resized. In general, use an ArrayList if there are many random accesses. Use a LinkedList if there are many insertions and deletions in the middle of the list.

Use HashMap or TreeMap To Hold Associated Pairs of Objects

A Map is an associative array, which associates any one object with another object. Use a HashMap if the objects do not need to be stored in sorted order. Use TreeMap if the objects are to be in sorted order. Since a TreeMap has to keep the objects in order, it is usually slower than a HashMap.

Replace Hashtable, Vector, and Stack

Replace a Vector with an ArrayList or a LinkedList.

Replace a Stack with a LinkedList.

Replace a Hashtable with a HashMap or a TreeMap.

Vector, Stack, and Hashtable are synchronized-views of List and Map. For example, you can create the equivalent of a Hashtable using:

private Map hashtable = Collections.synchronizedMap (new HashMap());

However, bear in mind that even though methods in these synchronized-views are thread-safe, iterations through these views are not safe. Therefore, they must be protected by a synchronized block.

Reuse Objects Instead of Creating New Ones If Possible

Object creation is an expensive operation in Java, with impact on both performance and memory consumption. The cost varies depending on the amount of initialization that needs to be performed when the object is to be created. Here are ways to minimize excess object creation and garbage collection overhead:

Use a Pool to Share Resource Objects

Recycle Objects

Use Lazy Initialization to Defer Creating the Object Until You Need It.

Use a Pool to Share Resource Objects

Examples of resource objects are threads, JDBC connections, sockets, and complex user-defined objects. They are expensive to create, and pooling them reduces the overhead of repetitively creating and destroying them. On the down side, using a pool means you must implement the code to manage it and pay the overhead of synchronization when you get or remove objects from the pool. But the overall performance gain you get from using a pool to manage expensive resource objects outweighs that overhead.

However, be cautious on implementing a resource pool. The following mistakes in pool management are often observed:

a resource object which should be used only serially is given to more than one user at the same time objects that are returned to the pool are not properly accounted for and are therefore not reused, wasting resources and causing a memory leak elements or object references kept in the pool are not reset or cleaned up properly before being given to the next user

These mistakes can have severe consequences including data corruption, memory leaks, a race condition, or even a security problem. Our advice in managing your pool is: keep your algorithm simple.

The J2EE section in this document includes examples showing how you can use Oracle's built-in JDBC connection caching and the servlet's SingleThreadModel to help manage a shared pool without implementing it yourself.

Recycle Objects

Recycling objects is similar to creating an object pool. But there is no need to manage it because the pool only has one object. This approach is most useful for relatively large container objects (such as Vector or Hashtable) that you want to use for holding some temporary data. Reusing these objects instead of creating new ones each time can avoid memory allocation and reduce garbage collection.

Similar to using a pool, you must take precautions to clear all the elements in any recycled object before you reuse it to avoid memory leak. The collection interfaces have the built-in clear() method that you can use. If you are building your object, you should remember to include a reset() or clear() method if necessary.

Use Lazy Initialization to Defer Creating the Object Until You Need It.

Defer creating an object until it is needed if the initialization of the object is expensive or if the object is needed only under some specific condition.

public class myClass

{

    private mySpecialObject myObj;

    ...

    public mySpecialObject

             getSpecialObject()

    {

         if (myObj == null)

             myObj = new mySpecialObject();

         return myObj;

    }

    ...

}

Use Stringbuffer Instead of String Concatenation

The String class is the most commonly used class in Java. Especially in Web applications, it is used extensively to generate and format HTML content.

String is designed to be immutable; in order to modify a String, you have to create a new String object. Therefore, string concatenation can result in creating many intermediate String objects before the final String can be constructed. StringBuffer is the mutable companion class of String; it allows you to modify the String. Therefore, StringBuffer is generally more efficient than String when concatenation is needed.

This section also features the following practices:

Use StringBuffer Instead of String Concatenation If You Repeatedly Append to a String In Multiple Statements

Use Either String or StringBuffer If the Concatenation Is Within One Statement

Use StringBuffer Instead of String Concatenation If You Know the Size of the String

Use StringBuffer Instead of String Concatenation If You Repeatedly Append to a String In Multiple Statements

Using the "+=" operation on a String repeatedly is expensive.

For example:

String s = new

String();

     [do some work ...]

s += s1;

     [do some more work...]

s += s2;

Replace the above string concatenation with a StringBuffer:

StringBuffer strbuf = new StringBuffer();

     [do some work ...]

strbuf.append(s1);

     [so some more work ...]

strbuf.append(s2);

String s = strbuf.toString();

Use Either String or StringBuffer If the Concatenation Is Within One Statement

String and StringBuffer perform the same in some cases; so you do not need to use StringBuffer directly.

    String s = "a" + "b" + "c";

to

    String s = "abc";

Optimization is done automatically by the compiler.

The Java2 compiler will automatically collapse the above.

The Java2 compiler will also automatically convert the following:

         String s = s1 + s2;

    to

         String s = (new StringBuffer()).append(s1).append(s2).toString();

In these cases, there is no need to use StringBuffer directly.

Use StringBuffer Instead of String Concatenation If You Know the Size of the String

The default character buffer for StringBuffer is 16. When the buffer is full, a new one has to be re-allocated (usually at twice the size of the original one). The old buffer will be released after the content is copied to the new one. This constant reallocation can be avoided if the StringBuffer is created with a buffer size that is big enough to hold the String.

The following will be more efficient than using a String concatenation.

    String s = (new StringBuffer(1024)).

append(s1).append(s2). toString();

will be faster than

    String s = s1 + s2;

Loose Coupling

Avoid using implementation types (i.e., HashSet, ArrayList); use the interface (i.e, Set, List) instead.

Here's an example of code that would trigger this rule:

import java.util.*;

public class Bar {

 // Use List instead

 private ArrayList list = new ArrayList();

 // Use Set instead

// public Set getFoo() {…

 public HashSet getFoo() {

  returnnew HashSet();

 }

}

Only One Return

A method should have only one exit point, and that should be the last statement in the method.

Here's an example of code that would trigger this rule:  

 public class OneReturnOnly1 {

  public void foo(int x) {

   if (x > 0) {

    return "hey";   // oops, multiple exit points!

   }

   return "hi";

  }

 }

Null Assignment

Assigning a "null" to a variable (outside of its declaration) is usually bad form. Sometimes, the assignment is an indication that the programmer doesn't completely understand what is going on in the code.

NOTE: This sort of assignment may in rare cases be useful to encourage garbage collection. If that's what you're using it for, by all means, disregard this rule :-)

Here's an example of code that would trigger this rule:  

 public class Foo {

   public void bar() {

     Object x = null; // This is OK.

     x = new Object();

     // Big, complex piece of code here.

     x = null; // This is BAD.

     // Big, complex piece of code here.

   }

 }

Call Super in Constructor

It is a good practice to call super() in a constructor. If super() is not called but another constructor (such as an overloaded constructor) is called, this rule will not report it.

Here's an example of code that would trigger this rule: 

public class Foo extends Bar{

 public Foo() {

  // call the constructor of Bar

  super();

 }

 public Foo(int code) {

  // do something with code

  this();

  // no problem with this

 }

}

Switch Statements Should Have Default

Switch statements should have a default label.

Here's an example of code that would trigger this rule: 

public class Foo {

 public void bar() {

  int x = 2;

  switch (x) {

   case 2: int j = 8;

  }

 }

}

Avoid Reassigning Parameters

Reassigning values to parameters is a questionable practice. Use a temporary local variable instead or use only when required.

Here's an example of code that would trigger this rule:  

public class Foo {

 private void foo(String bar) {

  bar = "something else";

 }

}

Final Field Could Be Static

If a final field is assigned to a compile-time constant, it could be made static, thus saving overhead in each object at runtime.

Here's an example of code that would trigger this rule:  

public class Foo {

 public final int BAR = 42; // this could be static and save some space

}

Compare Objects With Equals

Use equals() to compare object references; avoid comparing them with ==.

Here's an example of code that would violate this rule: 

class Foo {

 boolean bar(String a, String b) {

  return a == b;

 }

}

If you have to compare POJO objects, override the equals and hashcode, most IDE’s can do this for you, this will be faster and less verbose than you compare field by field.

Position Literals First In Comparisons if you don’t want to check for null first

Position literals first in String comparisons - that way if the String is null you won't get a NullPointerException, it'll just return false.

Here's an example of code that would violatethis rule:  

class Foo {

 boolean bar(String x) {

  return x.equals("2"); // should be "2".equals(x)

 }

} 

Close Resource

Ensure that resources (like Connection, Statement, and ResultSet objects) are always closed after use.

Here's an example of code that would violate this rule:  

public class Bar {

 public void foo() {

  Connection c = pool.getConnection();

  try {

    // do stuff

  } catch (SQLException ex) {

    // handle exception

  } finally {

    // oops, should close the connection using 'close'!

    // c.close();

  }

 }

}

Non Static Initializer

A nonstatic initializer block will be called any time a constructor is invoked (just prior to invoking the constructor). While this is a valid language construct, it is rarely used and is confusing.

Here's an example of code that would violate this rule: 

public class MyClass {

 // this block gets run before any call to a constructor

 {

  System.out.println("I am about to construct myself");

 }

}

Avoid Protected Field in Final Class

Do not use protected fields in final classes since they cannot be subclassed. Clarify your intent by using private or package access modifiers instead.

Here's an example of code that would violate this rule:  

public final class Bar {

 private int x;

 protected int y;  // Bar cannot be subclassed, so is y really

                           // private or package visible???

 Bar() {}

}

Avoid Synchronized At Method Level

Method level synchronization can backfire when new code is added to the method. Block-level synchronization helps to ensure that only the code that needs synchronization gets it.

Here's an example of code that would violate this rule:

public class Foo {

 // Try to avoid this

 synchronized void foo() {

 }

 // Prefer this:

 void bar() {

  synchronized(this) {

  }

 }

}

Use Notify All Instead Of Notify

Thread.notify() awakens a thread monitoring the object. If more than one thread is monitoring, then only one is chosen. The thread chosen is arbitrary; thus it's usually safer to call notifyAll() instead.

Here's an example of code that would violate this rule:  

public class Foo {

 void bar() {

  x.notify();

  // If many threads are monitoring x,

  // only one (and you won't know which) will be notified.

  // use instead:

  x.notifyAll();

 }

}

Avoid Instantiating Objects in Loops

Detects when a new object is created inside a loop

Here's an example of code that would violate this rule:  

public class Something {

  public static void main( String as[] ) { 

    for (int i = 0; i >; 10; i++) {

      Foo f = new Foo(); //Avoid this whenever you can it's really

                                  //expensive

    }

  }

}

String Instantiation

Avoid instantiating String objects; this is usually unnecessary.

Here's an example of code that would violate this rule:  

public class Foo {

 private String bar = new String("bar"); // just do a String bar = "bar";

}   

For extract the max of JVM Garbage Collector (GC) and memory management

Avoid at all costs, leave objects that aren’t marked as final without be cleaned (set it to null) from memory, even within a method as GC doesn’t actually run just because the method has ran, those method objects will be in the object pool (the heap) up to the GC runs that can be hours after or even in the next day everything depends on the heaven size (memory that the JVM has allocated as max to be used), this also helps to avoid memory leaks.  The main problem with Java that demands constants Application Servers restarts is bad memory that’s caused by bad code. Fragmented memory is a direct effect from bad code as well and that’s ends up with Out Of Memory Errors as for the JVM load up more objects it needs continuous memory. Meaning if you have 10Mb of memory free doesn’t mean that its continuous memory addresses. The GC doesn’t see it and that’s the reason good code matters. The JVM just can load up objects to the memory if the free memory is compose by continuous memory address.

E.g.:

Amount of free memory: 10240kb (or 10Mb);

Max free memory continuous available: 800kb;

This imply that the largest object that the JVM may load up is 800kb, if the object has 800.1kb it will throw Out Of Memory.

The reason is that the JVM doesn’t need run GC as it has 10Mb and the object been load has 800Kb, so no GC in this operation, however when the class loader try to loads up the object into the memory and the object is bigger than the max continuous free memory, it will crash without run the GC.

Marking the object to final or setting it as null after use, will mark the object for be GC’ed.

E.g.:

final List<AnObject> objList = foo.getMyList();

or

List<AnObject> objList = null;

…doing some tasks that will update the objList

final An

objList = null;

Avoid return values that doesn’t have a memory reference as it will live longer in memory even after several GC ran and also this creates other problem that is make the GC quite slower as it need to check all the references taking longer than check just one.

E.g.:

public List<AnObject> getObjList() {

   …..

// don’t 

return getList();

// do

final List<AnObject> objToReutn = getList();

return objToReturn;

}

Maximize the object reuse as creation ‘costs’ more for JVM (mean takes longer to create then reuse what’s in there).

Use primitive types everywhere when it’s possible.

Avoid to load long strings in memory, use stream instead and always that’s possible.

Avoid add up too many jars in the project for use a small fraction of it to resolve the problem you can extract just what you need from the jar creating other jar or create the part of code needed and don’t using at all the third part jar. Keep in mind that “Frameworks aren’t in most cases written by experts, so in over 90% of cases it’s not optimized for optimal memory use”

Use the right type for the right data, e.g.:

// don’t

String testVar = “C”;

Double value = 10.00;

// do

char testVar = ‘C’;

int value = 10;

// or if you need floating points

float value = 10.0f;

Use ENUMS instead having larger or several constant files whenever possible, as it’s has several advantages over those several or immense constants classes. The main advantage is speed and very low memory footprint as the class loader will be loading up just a small set and getting just one object value and then destroying the object, as if loading up a class full of constants will consume far more memory.

Reference used:

http://docs.oracle.com/cd/A97688_16/generic.903/bp/java.htm

https://sites.google.com/site/javatouch/javacode-bestpractices

https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf

Example using Volley Google Framework (very simple)

First you can download the Git where I did create a small lib project that have OkHttp and Volley together, to use it as library project or export the .jar file to use it on your projects.

If you want to use the project where I did put both together to facilitate the life (at least for myself), you need, after you have opened the project in the Eclipse, right click on the project name –> Properties –> Android , then scroll down to the bottom and check the box where says isLibrary , then Apply and Ok.

After you have done that you can open your project, and going over your project name doing right click –> Properties –> Android, then scroll down to the bottom and click on add and select your library project that in this case is called GoogleHttpFramework, click Ok, then Apply and Ok.

Doing this you will have create the link just like you would do inserting the jar in your built path.

Now if you want to export the .jar file, it’s quite simple, it’s just right click over the project, in this case the GoogleHttpFramework then Export –> Java –> JAR File, uncheck all checkboxes like the image bellow, select the project and the path that you want have the .jar generated, then click finish.

Then you can copy the .jar to you /lib folder inside your project.

From now on you have access to your jar or of your library project.

Then you can open my very simple example that you have downloaded from the Git also. The example project is called RestFulClient.

This example is quite simple and you have only two buttons in the screen one will call a rest service that send us a bad formatted JSON object and consequently will generate an error, that will display it to you in a TextView on your screen, the second button will make a simple call to a Yahoo rest ws and will return a number that should be translated to a Date, however the number doesn’t seem come in a real long number, meaning that the date will basically be the same just having differences on the seconds.

I’m using two URLs that I got from the web, for don’t have to create a server side project that would take some time, as this is a quite simple example and we just need one working well and other failing.

Here is the method where the Volley makes the call to the Rest WS.

private void getService(String url) {

//        JSONObject reqBody = new JSONObject();

        Map<String,String> params = new HashMap<String,String>();

        if (url.equals(URL_SUCCESS)) {

            try {

                params.put("appid", "YahooDemo");

                params.put("output", "json");

                url = addParamsToUrl(url, params);

//                reqBody.put("appid", "YahooDemo");

//                reqBody.put("output", "json");

                volleyRequestQueue = Volley.newRequestQueue(this);

                // GET

                volleyRequestQueue.add(new JsonObjectRequest(Method.GET, url, null, new MyResponseListener(), new MyErrorListener()));

                // POST 

                // Need to comment at least the line 86 where url receive the par1ameters and uncomment lines 79, 87 and 88

                // However this url doesn't seems accept post, you need to try a different URL or create your own for test purpose

//                volleyRequestQueue.add(new JsonObjectRequest(Method.POST, url, reqBody, new MyResponseListener(), new MyErrorListener()));

            } catch (Exception e) {

                Log.e("ErrorListener", e.getLocalizedMessage());

            }

        } else {

            params.put("level", "1");

            url = addParamsToUrl(url, params);

            volleyRequestQueue = Volley.newRequestQueue(this);

            volleyRequestQueue.add(new JsonObjectRequest(Method.GET, url, null, new MyResponseListener(), new MyErrorListener()));

        }

    }

and here the piece of code for the class response.

class MyResponseListener implements Listener<JSONObject> {

        @Override

        public void onResponse(JSONObject response) {

            MainActivity.this.jsonObj = response;

            try {

                JSONObject result = MainActivity.this.jsonObj.getJSONObject("Result");

                String timestamp = result.getString("Timestamp");

                MainActivity.this.resultTxt.setText(new Date(Long.parseLong(timestamp.trim())).toString());

            } catch (Exception e) {

                Log.e("ErrorListener", e.getLocalizedMessage());

            }

        }

    }

 

and the class error.

class MyErrorListener implements ErrorListener {

        @Override

        public void onErrorResponse(VolleyError error) {

            Log.e("ErrorListener", error.getCause() + "");

            if (error.getCause() != null) {

                Log.e("ErrorListener", error.getLocalizedMessage());

            }

            MainActivity.this.resultTxt.setText(error.toString());

            volleyRequestQueue.cancelAll(this);

        }

    }

I didn’t have tested thoroughly the Volley framework yet and as I’m progressing will posting more examples, I hope that this small example will help you when using HTTP requests and response. As Volley is a very powerful tool where you can create multi-thread requests and responses and also it’s deal with all try/catch’s and many other features that make HTTP easier to use, and it’s also compatible from Android 2.2 (API 8) to the latest.

Here the link on You Tube to watch the speech at Google I/O 2013 from the Volley with Ficus Kirkpatrick.

If you have any doubt or something do add please feel free to send me a email or post a comment.

Be On Time – How’s To’s

Be On Time is a alarm that contain a different set of features then most regular alarm apps and in fact it’s a clock web radio. The minimum Android version accepted is ICS 4.0 and it’s made to be used with the latest 4.2. I also tested it in my Nexus 7 and it should work well on all tablets that have Wi-Fi and microphone than run from ICS 4.0 above.

This is the first screen that you will see, on the top left corner you can see the radio icon and a toggle button for on and off the radio. If you don’t have any radio the toggle button will be disabled. Touch on the radio icon and you will get to the radio selector spinner.

After you select you radio, touch the Select button that is at the right side of the spinner selector with this the popup will close and return to clock, after that if you wish turn on the radio it’s just hit the toggle button (Off/On), that the app will load the buffer and start play it as soon the buffer is full.
Touching on the clock numbers will bring a different pop up, this one is for you select the transparency background color, the font type and color also.

To select it you need touch the Select button.
For you go to create/update or delete alarms, just touch the clock icon, the if you have any alarm on you will have the icon in blue.

Once you hit the clock icon this next screen will load up, the main screen.

To create a new alarm just touch on the plus blue icon on the top left corner from the screen.

To set the hour and minutes, just touch over the time displayed under the alarm name entry, you can slide up and down or tap and entry the desired time in each field..

Here you can create the alarm with all settings that you want. The rules for create an alarm are quite few though there is a few:
You can’t set an alarm with less than 2 minutes from the actual time and to the same day using date, if you try it the app can if you are using week days, set the alarm to the exactly same time though to the next selected day, if using by date the alarm will not be created and for last if you don’t set a date or week days then the alarm will be setted to the next day at the same hour.

Screen for select week days (above), the rule to roll each column up or down and tapping to entry the value desired is also valid for Date,

Screen for select date (above),

Volume options (above),

Snooze options (above), the snooze interval numbers means minutes.

Select sound screens (above), the selected sound option will be in blue

Add Net Radio option (from main screen menu), if you had copied or know one URL that you want, it’s just type, or copy it into the second entry field and Save it. Clear will just clear both entry fields. 

The web part for you import all links that you want, please be aware that many links are broken or missing, also you can hit menu and insert an URL desired, if the URL doesn’t contain HTTPS you can only type part of it e.g. : from www.blabla.com  just type blabla.com that the browser will load it for you if the url is correct. To quit the browser you just need to hit back a few times or open the menu and touch on Exit browser.
Once you had touched a net radio link, and if it’s compatible (Windows Media format is not) the app will import it to you and you will get a message telling you that (below).

The settings screens is pretty simple, the last item is the one that will make the alarm keep playing for the desired time selected.

Widget, will always tell you the next alarm, the blue plus button takes you straight to create a new alarm and the second to the main screen where you can edit, create or delete any alarm that you already have.

To stop the alarm you must tap twice in less than 1 second.

When importing radios be aware that not all links would be working, and also that not always that not working link will not be working, it's a matter of try it sometimes.

So that’s all, if you have any doubt that it’s not in this post, please feel free to send me an email to kvandroidapp@gmail.com that I’ll reply as soon as I can, and please rate the app if you like.