Java Tips, Tricks and Pitfalls

Java
Tips, Tricks and Pitfalls

KISS - Keep it Short and Simple!

KISS - Example 1 (Read properties from file)
Example of properties file:
hibernate.connection.username=myuser
hibernate.connection.password=secret
hibernate.c3p0.min_size=5
hibernate.c3p0.max_size=20
hibernate.c3p0.timeout=1800
hibernate.c3p0.max_statements=50

KISS - Example 1 (Implementation)
Overthinking
Elegance
Laziness
Experience
VS

KISS - Example 1 (Overthinking)
Let’s create a method with really self-describing name!
public Properties readAllLinesFromFileAndReturnPropertiesObject(File file) {
Properties properties = null;
// logic will be here
return properties;
}

KISS - Example 1 (Elegance)
Let’s create a method with really self-describing name!
public Properties readProperties(String filename) {
// logic will be here
return properties;
}

Let’s read the file and fill the properties!
BufferedReader bufferedReaderForFileWhichShouldContainsLines = new BufferedReader(
new InputStreamReader(new BufferedInputStream(new FileInputStream(file)))
);
String accumulatorForLineFromFile = null; properties = new Properties();
while ((accumulatorForLineFromFile = brffwhcl.readLine()) != null)
{
properties.setProperty(accumulatorForLineFromFile.split("=")[0],
accumulatorForLineFromFile.split("=")[1]);
}

KISS - Example 1 (Experience)
Let’s read the file and fill the properties!
public Properties readProperties(String filename) {
Properties properties = new Properties();
properties.load(new FileInputStream(filename));
return properties;
}

Let’s handle some exceptions!
if (file != null) {
...
} else {
throw new IllegalArgumentException("file which should contains all needed information "
+
"to init Properties object is null, that means that Java can't work with it, "
+
"please check your code and make sure that you are passing valid arguments",
new NullPointerException()
);
}
return properties;
}

And several more...
if (file != null) {
if (file.exists()) {
if (file.canRead()) {
try {
BufferedReader
bufferedReaderForFileWhichShouldContainsLines = new BufferedReader(
new InputStreamReader(
new BufferedInputStream(
new FileInputStream(file)
)
)
);
try {
String accumulatorForLineFromFile = null;
properties = new Properties();
while ((accumulatorForLineFromFile
=
bufferedReaderForFileWhichShouldContainsLines.readLine()) != null) {
properties.setProperty(
accumulatorForLineFromFile.split("=")[0],
accumulatorForLineFromFile.split("=")[1]
);
}
} catch (IOException ioException) {
throw new IllegalArgumentException("file which should contains all needed information "
+
"to init Properties object is not null, but it isn't suitable for reading, " +
"that means that Java can't work with it, " +
new IOException(ioException)
);
} finally {
try {
bufferedReaderForFileWhichShouldContainsLines.close();
} catch (IOException ioException) {
System.err.printf("Can't close bufferedReaderForFileWhichShouldContainsLines: %s",
ioException.getMessage()
);
}
}
} catch (FileNotFoundException fileNotFoundException) {
throw new IllegalArgumentException("file which should contains all needed information " +
"to init Properties object is not null, but it not found, " +
new FileNotFoundException(fileNotFoundException.getMessage())
);
}
} else {
"to init Properties object is not null, but it now unreadable, " +
new IllegalAccessException()
);
}
} else {
"to init Properties object is not null, but it isn't exists, " +
new IllegalAccessException()
);
}
} else {
"to init Properties object is null, that means that Java can't work with it, " +
new NullPointerException()
);
}
return properties;
}

KISS - Example 1 (Laziness)
Let’s handle some exceptions!
public Properties readProperties(String filename) throws IOException {
Properties properties = new Properties();
properties.load(new FileInputStream(filename));
return properties;
}

Naming best & bad practices
Programming routine:

Naming best practices
● Keep all names close to context and self-describing
○ But avoid “secret knowledge”
○ Share the context via javadoc or comments

● Variable type should be obvious
○ That doesn’t mean that name should contain Type

● Boolean variables/methods names should be suitable
for the sentence: “if <variable_name> then ...?”

● Methods names should answer the question “what to do?”

● Methods names should answer the question “what to do?”
● Type names might contain parent names

Naming bad practices
● Using words that means nothing: obj, data, value, tmp...
a. There is always place for exceptions

● Fake/Wrong variable type
a. This might cost a burned chair...

● Single-character names: w, t, f ... o, m, g
a. Especially without any context - 100% burned chair

● Fake/Incomplete names of the methods

● Fake/Incomplete names of the methods
● Public argument names based on secret knowledge

Dirty and Pure methods
Hello, my name is side-effect...
public int[] sortArray(int[] array) {
Arrays.sort(array);
return array;
}

And sometimes I’m not obvious at all…
public <T> T[] sortArray(T[] array) {
if (array == null || array.length < 2) return array;
Comparator<T> comparator = null;
T[] tmpArray = checkAndReturnArray(array);
T notNullElement = null;
for (int i = 0; i < tmpArray.length && notNullElement == null; notNullElement = tmpArray[i++]) ;
if (notNullElement == null) return array;
if (notNullElement instanceof Comparator) { comparator = (Comparator<T>) notNullElement; }
else if (notNullElement instanceof Comparable) {
comparator = (o1, o2) -> {
if (o1 == null) return 1; if (o2 == null) return -1; return ((Comparable<T>) o1).compareTo(o2);
};
}
if (comparator == null) return array;
Arrays.sort(tmpArray, comparator);
return tmpArray;
}

Here's Johnny!
/**
* Checks array and returns copy if Mars is in the zenith of Saturn
*/
public <T> T[] checkAndReturnArray(T[] array) {
return (array != null)
? ((System.currentTimeMillis() > (42 * 64 * 30 * 365))
? ((System.getenv("magic") == null)
? array : null) : array) : null;
}

Immutability and final keyword
If you can’t change the methods,
you can change the arguments...

What is immutability?
class Immutable {
private final String immutableField;
public Immutable(String immutableField) {
this.immutableField = immutableField;
}
public String getImmutableField() {
return immutableField;
}
}
Examples:
String, Integer, File, URL...

What is immutability?
class Immutable {
private final String immutableField;
public Immutable(String immutableField) {
this.immutableField = immutableField;
}
public String getImmutableField() {
return immutableField;
}
}
Examples:
String, Integer, File, URL...
What is mutability?
class Mutable {
private List<String> mutableField;
public List<String> getMutableField() {
return mutableField;
}
public void setMutableField(List<String> mutableField) {
this.mutableField = mutableField;
}
}
Examples:
ArrayList, Arrays, StringBuilder...

Why immutability is good?
● Preventing side-effects
● Thread-safe
● Easy to debug
● Easy to implement
● Easy to extend
● Easy to scale

Why immutability is good?
● Preventing side-effects
● Thread-safe
● Easy to debug
● Easy to implement
● Easy to extend
● Easy to scale
Why immutability is bad?
● Real world isn’t immutable
● Constraints you
● Not always convenient
● Increases memory usage
● Performance degradation
● There is always will be an
exception...

Keyword final can be used with:
● Variables
○ final Object someField;

● Variables
● Methods
○ final public void someMethod() { ... }
○ public void someMethod(final Object argument) { ... }

● Variables
● Methods
○ final public void someMethod() { ... }
○ public void someMethod(final Object argument) { ... }
● Classes
○ public final class Example3;

try-catch-finally pitfalls
Simple puzzle?
public static int puzzle() {
try {
return 5;
} catch (Exception ex) {
return 10;
} finally {
return 15;
}
}

try pitfalls
● It’s a new scope…
● Each line might raise exception
● catch or finally is required
● Try with resources?
○ Custom AutoCloseable implementation
○ Implicit side-effect

catch pitfalls
● Type erasing
● Performance degradation
● Exception-oriented logic

finally pitfalls
● WILL BE EXECUTED ALWAYS!!!
○ Except for that moment, in which you will really need this...
● Might cause performance degradation
● Newer return value in finally
○ But sometimes...

Early exception handling
Exception handling
public int someMethod(String arg1, String arg2) {
final int defaultValue = 42;
int value = 0;
try {
int int1 = Integer.parseInt(arg1);
value = int1 / int2;
System.err.println(ex);
return defaultValue;
}
return value;
}

Exception handling
int value = 0;
try {
value = int1 / int2;
System.err.println(ex);
}
return value;
}
if (notNumber(arg1) || notNumber(arg2)) {
}
if (int2 == 0) {
}
int value = int1 / int2;
return value;
}

● Objects.requireNonNull(argument); (throw early)

● Use IllegalArgumentException() (throw early)

● Use UnsupportedOperationException() (throw early)

● Delegate exception handling, use throws (catch late)

● Delegate exception handling, use throws (catch late)
● Write javadoc
● Write logs

Why null is bad?
● More than 2500 NPE defects in our Jira

Why null is bad?
● null is low-level concept

Why null is bad?
● Zero information

Why null is bad?
● null instanceof Type --> false

Why null is bad?
● int value = (Integer) null; --> NPE

Why null is bad?
● Many methods uses .toString() --> NPE
○ String.valueOf(obj) - solves this issue

Why null is bad?
● Many methods uses .toString() --> NPE
○ String.valueOf(obj) - solves this issue
● Null-oriented programming is legacy
○ Use Optional<T> instead

Lean refactoring
● Don’t broke tests (Red-Green-Refactor)

Lean refactoring
● Don’t change signatures

Lean refactoring
● Don’t change parameters order
○ Especially for constructors

Lean refactoring
● Don’t change contract

Lean refactoring
● Don’t change contract
● Use @Deprecated

Abusing Java
Just because you can, it doesn’t mean you should...
● Use enum as Singleton

Abusing Java
● Use static as Singleton

Abusing Java
● Use reflection
○ Especially for internal JDK classes

Abusing Java
● Use reflection
● Use interface just because of signature

Abusing Java
● Use reflection
● Use inheritance as aggregation/delegation

Abusing Java
● Use reflection
● Use inheritance as aggregation/delegation
● ...
● If it works, it doesn’t mean it’s good.

SOLID in the nutshell
● S - Single responsibility

● O - Opened for extension, but closed for changes

● L - Liskov substitution, children should keep parents
contracts.

contracts.
● I - Interface segregation is better than God-interface.

contracts.
● I - Interface segregation is better than God-interface.
● D - Dependency inversion, build dependencies over
abstractions, not over implementations.

Q&A Session (the end)
Attention!
Thanks for your attention!

Java Tips, Tricks and Pitfalls

More Related Content

What's hot

Similar to Java Tips, Tricks and Pitfalls

Recently uploaded

Java Tips, Tricks and Pitfalls