Why should we use getters and setters in POJOs?

There are quite a few reasons to use getters and setters in POJO.

Let's first take a look at a simple POJO and then we will discuss the uses of getter and setter:

package com.prinavtech.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

Getters and Setters are primarily used for two main purposes of Object Oriented Programming:

1. Abstraction
2. Encapsulation

The advantages of using these are:

1. You can restrict the accessibility of an attribute by using access modifiers.
   Eg: We can make FirstName readable only by making the getter private

2. Can validate a field directly inside a pojo.
Eg: we can make sure that the age of a Person can be between 0<100.

3. The above two points are in support of Encapsulation and Abstraction.

4. In Java if you declare the variables as instance variables, it will make your code slower. Run a test and you will see that accessing and setting variables via setters and getters are faster than setting them directly as instance variables.

For more read this stackoverflow post.

down vote

NoClassDefFoundError vs ClassNotFoundException

Here are few differences between NoClassDefFoundError vs ClassNotFoundException:

1) NoClassDefFoundError is an Error which is unchecked in nature, i.e. doesn't require try-catch or finally block. On the other hand ClassNotFoundException is a checked Exception and requires mandatory handing using either try with catch block or try with finally block, failure to do so will result in compile time error.

2) If you are experiencing NoClassDefFoundError in J2EE environment, there could be a host of reasons. One of them being multiple class loaders and visibility of class among them.

3) Often java.lang.ClassNotFoundException is thrown as result of following method call, Class.forName(), ClassLoader.findSystemClass() and ClassLoader.loadClass().

4) Another difference between NoClassDefFoundError and ClassNotFoundException is that NoClassDefFoundError is a LinkageError and can come during linking, while java.lang.ClassNotFoundException is an Exception and occurs during runtime.

That's all on difference between NoClassDefFoundError vs ClassNotFoundException in Java.

Just remember these list of difference while debugging or troubleshooting NoClassDefFoundError or ClassNotFoundException, this will reduce confusion and help to solve problem quickly.

Best Practices for a Java Developer

This document is inspired from popular open source communities' coding standards, such as Spring Framework Code Style and Oracle Java Code Conventions. Some of the ideas also come from this great article : 7 reasons clean code matters.

1. General Development rules for Good Developers

Please don’t:

·       commit code that does NOT even compile. Usually this happens when a developer only checks in part of his work.

·       commit code that can't pass tests. If tests fail, it is recommended to update failed tests before checking in changes. The moment a test failed because of the change you made, is the best time to revisit, refactor the test.

·       comment out code that is now obsolete

·       insert comments around each change.

·       make things public which are not required by end users.

·       Combine multiple issues into a single commit, especially if they are unrelated or only loosely related. This is true even if the changes affect the same files.

Please do:

·       comment code whose function is not obvious;

·       update documentation (e.g., javadoc, this wiki, etc.). All public methods should have javadoc explaining what they do.

·       try to provide a unit test that shows a bug was indeed fixed or the new functionality truly works

·       Applying DRY(don't repeat yourself) Principle whenever possible.

2. Java Code Style

The following things may not necessarily be the best practice, but are widely practiced in the world of developers.

2.1 Source file

2.1.1 File encoding: UTF-8

All source files should be encoded in UTF-8.

2.1.2 Enforced uniform column width: 90

We need to strive for consistent line lengths in all source code we write. An industry standard is 80 characters per line. Google recommends 80 or 100 characters per line. Let's make it 90, same as Spring Framework.

2.1.3 Indentation

The issue of using hard tabs or spaces is an ongoing debate in the programming community. Some programmers feel that spaces instead of tabs increase cross-platform functionality. Others, believe the opposite, that hard tabs increase cross-platform functionality.

This is what Spring Framework does

·       Indentation uses tabs (not spaces)

·       Unix (LF), not DOS (CRLF) line endings

·       Eliminate all trailing whitespace

2.1.4 Formatting

Braces mostly follow the Kernighan and Ritchie style (a.k.a., "Egyptian brackets") for nonempty blocks and block-like constructs

·       No line break before the opening brace but prefixed by a single space

// bad practice : no space before opening brace if(true){ // implementation } // bad practice : link break before opening brace if(true) { // implementation }

·       Line break after the opening brace

// bad practice: no line break after the opening brace if(true) { //some statement after opening brace }

·       Line break before the closing brace

// bad practice : no line break before the closing brace if(true) { /*some statement before closing brace*/}

// This is good practice

if(true) { // implementation }

2.1.5 Naming

·       Constant names use CONSTANT_CASE : all uppercase letters, with words separated by underscores. Constants should be static final

public static final int DEFAULT_QUERY_COUNT = 25;

·       Local variables have no rule, but should be meaningful.

Some of the reasons for this naming conversion.

·       within any code blocks, you are able to tell the scope/type of any variables without any effort

·       'this' keyword can be avoided without causing confliction/confusion or compiler errors

2.1.6 Use of @Override

Always add @Override on methods overriding a method declared in a super type.

2.1.8 Source file structure/organization

The following can be an example how a Java class should be written i.e. how and where to declare variables and so on.

1.     static fields

2.     normal fields (instance variables)

3.     constructors

4.     public and private method

5.     static methods (if any. This should be discouraged, because java static breaks OO)

6.     equals, hashCode, and toString()

7.     getters and setters

EmployeeDAO.java

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

package com.coding.example; import org.slf4j.Logger; import org.slf4j.LoggerFactory; // more imports ... /** * Document goes here * * @author Pritam Banerjee */ public class EmployeeDAO { // 1. static fields private static final Logger LOGGER = LoggerFactory.getLogger(EndecaQuery.class); // 2. normal fields(instance variables) private QueryService _service; // 3. constructor public EmployeeDAO () { } // 4. methods public Query createQuery() { // implementation goes here } // 6. equals, hashCode, toString() @Override public boolean equals(Object argObj) { // implementation goes here } @Override public int hashCode() { // implementation goes here } @Override public String toString() { // implementation goes here } // 7. getters and setters public QueryService getService() {    return _service; } public void setService(QueryService argService) {    _service = argService; } }

2.2 Test

Each test class should end with a 'Test' suffix, e.g. EmployeeDAOTest. It is also recommended, although not strictly required to name the test with a 'test' prefix, e.g. testEmployeeClassType().