NO. 1: Neglecting Existing Libraries
It's unquestionably a mix up for Java Developers to slight the endless measure of libraries written in Java. Just before reexamining the wheel, attempt to chase for offered libraries – a few of them have been cleaned during the time of their reality and are thoroughly allowed to utilize. These could be logging accumulations, as logback and Log4j, or system applicable accumulations, as Netty or Akka. A couple of the libraries, for example, Joda-Time, have really come to be an accepted necessity.
NO. 2: Missing the ‘break’ Keyword in a Switch-Case Block
Fall through behavior in switch statements is often useful; however,
missing a “break” keyword when such behavior is not desired can lead to
disastrous results. If you have forgotten to put a “break” in “case 0” in the
code example below, the program will write “Zero” followed by “One”, since the
control flow inside here will go through the entire “switch” statement until it
reaches a “break”. For example:
public
static void switchCasePrimer() {
int
caseIndex = 0;
switch
(caseIndex) {
case
0:
System.out.println("Zero");
case
1:
System.out.println("One");
break;
case
2:
System.out.println("Two");
break;
default:
System.out.println("Default");
}
}
In
most cases, the cleaner solution would be to use polymorphism and move code
with specific behaviors into separate classes. Java mistakes such as this one
can be detected using static code analyzers, e.g. FindBugsand PMD.
NO. 3: Forgetting to Free Resources
This mistake may lead to resources leaked or memory occupied by no
longer used objects.
public static void copyFile(File sourceFile, File destFile) {
FileChannel sourceChannel = null;
FileChannel destChannel = null;
try {
sourceChannel
= new FileInputStream(sourceFile).getChannel();
destChannel = new FileOutputStream(destFile).getChannel();
sourceChannel.transferTo(0,
sourceChannel.size(), destChannel);
} catch (IOException ex) {
ex.printStackTrace();
}
}
A solution to this is using the try-with-resources structure
available since Java 7, which automatically closes the resources. example, the above code can be re-written like the following code:
public static void copyFile(File sourceFile, File destFile) {
try (
FileChannel
sourceChannel = new FileInputStream(sourceFile).getChannel();
FileChannel destChannel
= new FileOutputStream(destFile).getChannel();
) {
sourceChannel.transferTo(0,
sourceChannel.size(), destChannel);
} catch (IOException ex) {
ex.printStackTrace();
}
}
NO. 4: Memory Leaks
Memory leaks in Java can
happen in various ways, but the most common reason is everlasting object
references, because the garbage collector can’t remove objects from the heap
while there are still references to them. One can create such a reference by
defining class with a static field containing some collection of objects, and
forgetting to set that static field to null after the collection is no longer
needed. Static fields are considered GC roots and are never collected.
Another potential explanation for such memory spills is a gathering of items referencing each other, causing round conditions so the junk jockey can't choose whether these articles with cross-reliance references are required or not. Another issue is spills in non-load memory when JNI is utilized.
NO. 5: Excessive Garbage Allocation
Excessive
garbage allocation may happen when the program makes a ton of fleeting items. The junk jockey works consistently, expelling unneeded articles from memory, which impacts applications' execution adversely.
An Example:
String
oneMillionHello = "";
for
(int i = 0; i < 1000000; i++) {
oneMillionHello = oneMillionHello + "Hello!";
}
System.out.println(oneMillionHello.substring(0,
6));
In
Java, strings are immutable. So, on each iteration a new string is created. To
address this we should use a mutable StringBuilder:
StringBuilder
oneMillionHelloSB = new StringBuilder();
for (int i = 0; i < 1000000; i++) {
oneMillionHelloSB.append("Hello!");
}
System.out.println(oneMillionHelloSB.toString().substring(0,
6));
While the principal rendition requires a considerable amount of time to execute, the form that utilizations StringBuilder produces an outcome in an essentially less measure of time.
NO. 6: Using Null References without Need
Maintaining a strategic distance from inordinate utilization of invalid is a decent practice. For instance, it's desirable over return discharge exhibits or accumulations from techniques rather than nulls, since it can help avert NullPointerException.
Consider the accompanying technique that navigates an accumulation acquired from another strategy, as demonstrated as follows:
List<String>
accountIds = person.getAccountIds();
for
(String accountId : accountIds) {
processAccount(accountId);
}
If
getAccountIds() returns null when a person has no account, then
NullPointerException will be raised.To settle this, an invalid check will be required. Be that as it may, if rather than an invalid it restores a void rundown, at that point NullPointerException is not any more an issue. Besides, the code is cleaner since we don't have to invalid check the variable accountIds.
To manage different situations when one needs to stay away from nulls, distinctive techniques might be utilized. One of these techniques is to utilize Optional sort that can either be a void protest or a wrap of some esteem:
Optional<String>
optionalString = Optional.ofNullable(nullableString);
if(optionalString.isPresent())
{
System.out.println(optionalString.get());
}
In
fact, Java 8 provides a more concise solution:
Optional<String>
optionalString = Optional.ofNullable(nullableString);
optionalString.ifPresent(System.out::println);
NO. 7: Ignoring Exceptions
In This case the exceptions occurred, the code can fail silently
which adds difficulty in finding the problem.
look at the following program:
public class Sum {
public static void main(String[] args) {
int a = 0;
int b = 0;
try {
a
= Integer.parseInt(args[0]);
b
= Integer.parseInt(args[1]);
} catch (NumberFormatException
ex) {
}
int sum = a + b;
System.out.println("Sum
= " + sum);
}
}
program calculates the sum of two numbers passed via command-line
arguments. Note that the catch block is left empty. If we try to run this
program by the following command line:
java Sum 123 456y
will fail silently:
Sum = 123
It’s because the second argument 456y causes a NumberFormatException to
be thrown, but there’s no handling code in the catch block so the program
continues with incorrect result.
So to avoid such potential problem, always handle exceptions at least
by printing the stack trace to inform the error when it happens:
try {
a = Integer.parseInt(args[0]);
b = Integer.parseInt(args[1]);
} catch (NumberFormatException ex) {
ex.printStackTrace();
}
It save your hours of debugging later if the problem occurs.
NO. 8:
Modifying a collection while iterating it
This exemption happens when a gathering is changed while repeating over it utilizing techniques other than those gave by the iterator protest. For instance, we have a rundown of caps and we need to evacuate every one of those that have ear folds:
List<IHat>
hats = new ArrayList<>();
hats.add(new
Ushanka()); // that one has ear flaps
hats.add(new
Fedora());
hats.add(new
Sombrero());
for
(IHat hat : hats) {
if (hat.hasEarFlaps()) {
hats.remove(hat);
}
}
If
you run this code, “ConcurrentModificationException” will be raised since the
code modifies the collection while iterating it. The same exception may occur
if one of the multiple threads working with the same list is trying to modify
the collection while others iterate over it. Simultaneous change of accumulations in numerous strings is a characteristic thing, yet ought to be treated with regular apparatuses from the simultaneous programming tool kit, for example, synchronization locks, exceptional accumulations embraced for simultaneous adjustment, and so forth. There are inconspicuous contrasts to how this Java issue can be settled in single strung cases and multithreaded cases. The following is a concise discourse of some ways this can be dealt with in a solitary strung situation:
Gather questions and evacuate them in another circle
Gathering caps with ear folds in a rundown to expel them later from inside another circle is a conspicuous arrangement, however requires an extra accumulation for putting away the caps to be expelled:
List<IHat>
hatsToRemove = new LinkedList<>();
for
(IHat hat : hats) {
if (hat.hasEarFlaps()) {
hatsToRemove.add(hat);
}
}
for
(IHat hat : hatsToRemove) {
hats.remove(hat);
}
Use
Iterator.remove method
This
approach is more concise, and it doesn’t need an additional collection to be
created:
Iterator<IHat>
hatIterator = hats.iterator();
while
(hatIterator.hasNext()) {
IHat hat = hatIterator.next();
if (hat.hasEarFlaps()) {
hatIterator.remove();
}
}
Utilizing List Iterator’s methods
Utilizing the listiterator is suitable when the adjusted gathering actualizes List interface. Iterators that execute List Iterator interface bolster evacuation operations, as well as include and set operations. ListIterator actualizes the Iterator interface so the illustration would look practically the same as the Iterator evacuate technique. The main distinction is the kind of cap iterator, and the way we acquirethat iterator with the “listIterator()” method. The snippet
below shows how to replace each hat with ear flaps with sombreros using
“ListIterator.remove” and “ListIterator.add” methods:
IHat
sombrero = new Sombrero();
ListIterator<IHat>
hatIterator = hats.listIterator();
while
(hatIterator.hasNext()) {
IHat hat = hatIterator.next();
if (hat.hasEarFlaps()) {
hatIterator.remove();
hatIterator.add(sombrero);
}
}
With
ListIterator, the remove and add method calls can be replaced with a single
call to set:
IHat
sombrero = new Sombrero();
ListIterator<IHat>
hatIterator = hats.listIterator();
while
(hatIterator.hasNext()) {
IHat hat = hatIterator.next();
if (hat.hasEarFlaps()) {
hatIterator.set(sombrero); // set
instead of remove and add
}
}
Utilize stream strategies presented in Java 8 With Java 8, software engineers can change a gathering into a stream and channel that stream as indicated by a few criteria. Here is a case of how stream programming interface could enable us to channel caps and evade
“ConcurrentModificationException”.
hats
= hats.stream().filter((hat -> !hat.hasEarFlaps()))
.collect(Collectors.toCollection(ArrayList::new));
The
“Collectors.toCollection” technique will make another ArrayList with separated caps. This can be an issue if the separating condition were to be fulfilled by an expansive number of things, bringing about a huge ArrayList; subsequently, it ought to be use with mind. Utilize List.removeIf strategy displayed in Java 8 Another arrangement accessible in Java 8, and plainly the most succinct, is the utilization of the “removeIf”
method:
hats.removeIf(IHat::hasEarFlaps);
That’s
it. Under the hood, it uses “Iterator.remove” to accomplish the behavior.
Utilize specialized collections
On the off chance that at the earliest reference point we chose to utilize "CopyOnWriteArrayList" rather than "ArrayList", at that point there would have been no issue by any means, since "CopyOnWriteArrayList" gives adjustment techniques, (for example, set, include, and evacuate) that don't change the support exhibit of the gathering, but instead make another altered form of it. This permits emphasis over the first form of the gathering and alterations on it in the meantime, without the danger of "ConcurrentModificationException". The downside of that gathering is self-evident - era of another accumulation with every adjustment.
There
are other collections tuned for different cases, e.g. “CopyOnWriteSet” and
“ConcurrentHashMap”.
Another
possible mistake with concurrent collection modifications is to create a stream
from a collection, and during the stream iteration, modify the backing
collection. The general rule for streams is to avoid modification of the
underlying collection during stream querying. The following example will show
an incorrect way of handling a stream:
List<IHat>
filteredHats = hats.stream().peek(hat -> {
if (hat.hasEarFlaps()) {
hats.remove(hat);
}
}).collect(Collectors.toCollection(ArrayList::new));
The strategy look accumulates every one of the components and plays out the gave activity on every one of them. Here, the activity is endeavoring to expel components from the basic rundown, which is incorrect. To maintain a strategic distance from this, attempt a portion of the strategies portrayed previously.
NO. 9: Breaking Contracts
Sometimes,
code that is provided by the standard library or by a third-party vendor relies
on rules that should be obeyed in order to make things work. For example, it
could be hashCode and equals contract that when followed, makes working
guaranteed for a set of collections from the Java collection framework, and for
other classes that use hashCode and equals methods. Disobeying contracts isn’t
the kind of error that always leads to exceptions or breaks code compilation;
it’s more tricky, because sometimes it changes application behavior without any
sign of danger. Erroneous code could slip into production release and cause a
whole bunch of undesired effects. This can include bad UI behavior, wrong data
reports, poor application performance, data loss, and more. Fortunately, these
disastrous bugs don’t happen very often. I already mentioned the hashCode and
equals contract. It is used in collections that rely on hashing and comparing
objects, like HashMap and HashSet. Simply put, the contract contains two rules:
If
two objects are equal, then their hash codes should be equal.
If
two objects have the same hash code, then they may or may not be equal.
Breaking
the contract’s first rule leads to problems while attempting to retrieve
objects from a hashmap. The second rule signifies that objects with the same
hash code aren’t necessarily equal. Let us examine the effects of breaking the
first rule:
public
static class Boat {
private String name;
Boat(String name) {
this.name = name;
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() !=
o.getClass()) return false;
Boat boat = (Boat) o;
return !(name != null ?
!name.equals(boat.name) : boat.name != null);
}
@Override
public int hashCode() {
return (int) (Math.random() * 5000);
}
}
As
you can see, class Boat has overridden equals and hashCode methods. However, it
has broken the contract, because hashCode returns random values for the same
object every time it’s called. The following code will most likely not find a
boat named “Enterprise” in the hashset, despite the fact that we added that
kind of boat earlier:
public
static void main(String[] args) {
Set<Boat> boats = new
HashSet<>();
boats.add(new Boat("Enterprise"));
System.out.printf("We have a boat
named 'Enterprise' : %b\n", boats.contains(new Boat("Enterprise")));
}
Another
example of contract involves the finalize method. Here is a quote from the
official java documentation describing its function:
”The
general contract of finalize is that it is invoked if and when the JavaTM
virtual machine has determined that there is no longer any means by which this
object can be accessed by any thread (that has not yet died), except as a
result of an action taken by the finalization of some other object or class
which is ready to be finalized. The finalize method may take any action,
including making this object available again to other threads; the usual
purpose of finalize, however, is to perform cleanup actions before the object
is irrevocably discarded. For example, the finalize method for an object that
represents an input/output connection might perform explicit I/O transactions
to break the connection before the object is permanently discarded.“
One
could decide to use the finalize method for freeing resources like file
handlers, but that would be a bad idea. This is because there’s no time
guarantees on when finalize will be invoked, since it’s invoked during the
garbage collection, and GC’s time is indeterminable.
NO. 10: RAW TYPE USAGE
Raw types, according to Java specifications, are types that are either
not parametrized, or non-static members of class R that are not inherited from
the superclass or superinterface of R. There were no alternatives to raw types
until universal types were presented in Java. It sustains generic programming
considering that version 1.5, and generics were unquestionably a significant
improvement. Nonetheless, due to backwards compatibility factors, a mistake has
been left that can potentially break the type system
.
