Common mistakes JAVA developers do!

JAVA is one of the mostly used programming language around the GLOBE.

There are some bad practices/common mistakes which JAVA developers follow. So let’s know what are they and try to understand them. Before we start, I want to share a quote.

A good developer is the one who knows ‘what not to use’ and ‘what to use when’. #UNKNOWN

           1) Null pointer exception:

           Generally every developer makes a mistake
           in handling the “null” values. While writing the code
           sometimes developer thinks that ‘the particular’ field
           can never be null and knowingly or   
           unknowingly, developer doesn’t write code for null
           check. This may end-up in failure. So it’s always a
           good practice to have a null-check whenever possible.

           2) Returning “null” value:

           Getting ‘null’ as returned value will not explain the 
           intent of the “null”.
           Sometimes it confuses developers that whether the
           null is one of the expected value or is it coming
           because data is not available or is there any
           exception came in that method and it returned null. 
           It’s a good practice to avoid returning null
           whenever possible.

Scenario:

When using collection objects then code should return an empty collection instead of a null object.
This will reduce headache of handing “null” check also.

List<String> list = Collections.emptyList();

Note: Same thing we can apply to Map and Set also.

3) Comparing String constant with another string:

Suppose the scenario is that code wants to check whether the returned city name is “XYZ” or not (and City field can be null i.e. one of the expected value).

Below is how most of the developers check this:
 
if(getUserCity().equalsIgnoreCase("XYZ")) {}

Here code may return a ‘null pointer exception’ if the method getUserCity () returns null and calling a method on null object will cause ‘null pointer exception’. So we avoid this situation by writing the code this way:

if(“XYZ”.equalsIgnoreCase(getUserCity()) {}

      4) Confusion between .equals() and == :

The “==” operator should be used only when code wants to check whether two objects belong to a same location in the memory or not.

      Scenario1:

String obj1 = new String("xyz");
String obj2 = obj1;

      if(obj1 == obj2)
{
   System.out.println("TRUE");
}
else
{
  System.out.println("FALSE");
}

OUTPUT:  TRUE.

     By default the .equals() method also compare the
     location of the objects in the memory. But developer
     should not use this to compare locations instead
     override the method and compare the values of the
     object.

    Scenario2:
    
     String class in java overrides this method from Object
     class and compares the values.

String obj1 = new String("xyz");

            String obj2 = obj1;

String obj3 = new String("xyz");

            if(obj1.equals(obj2))

            {

               System.out.println("TRUE");

            }

            if(obj1.equals(obj3))

            {

               System.out.println("TRUE");

            }

            else

            {

              System.out.println("FALSE");

      }
 

      OUTPUT:  TRUE
      TRUE.

     5) Confusion between passing by value, and passing by reference:
Most of the developers think that in Java, Objects are passed by reference, and primitives variables are passed by value. But this is not correct. In JAVA everything is passed by value only.

Scenario:

            public void changeName(String name)

            {  

               name = new String("ABC");
            }

String name = new String("XYZ");

changeName (name);

Here we are passing the value of name to changeName(),  it does not pass the object that name points to.

     6)  Int  vs  Integer:

Integer length = BOGUS.size();

for (Integer i = 0;i < size; i++)

The above approach is not a good practice. Developer should use int whenever possible.
Integer should be used when value of that Integer object can be null, which is not the case in the above mentioned scenario. Integer is very much bulkier than int.

Also using Integer object gives an extra headache of boxing and unboxing to the code.