Java Best Practices



Avoid Java serialization if possible

Serialization was intended as a utility within the Java language, which allows objects to be converted into bytes (serialized), send to another endpoint, and reconstructed as an object again (deserialized). This is necessary since java objects only exists within the JVM and can therefore not be send directly.



78. Use Synchronize When Handling Mutable Methods
When working with threads, synchronize on mutable methods becomes a valuable resource. This is because of two reasons:

Synchronize ensure the method can only be accessed by one thread at a time. Any thread attempting to execute the method while it is already in use, will be put on hold until the method is available again.
Because the threads are set to wait for each other, synchronize also guarantee that each thread will be able to see changes to the mutable method made by previous threads.
A mutable method could for example be a method providing an incremental serial number based on a field instance.



Exceptions only for exceptional scenarios

Exceptions are a way of causing the system to quickly alert the system of some unexpected scenario. However, some people might start using exceptions as a functionality of the system and start relying on the to convey acceptable scenarios.


General Programming

Minimize scope of local variables.

Local variables should be contained within the smallest scope possible.

The most optimal solution is therefore to create the local variable the same place as it is used. Thereby increasing the readability of the code and minimizing the chance of misusing the variable.



Assert method arguments validity
Whenever an object is given in as a method argument, it should be asserted in terms of validity as the first thing.

This can be done with something as Objects.requireNonNull(arg), which will throw an exception if the argument is null.

Additionally, if you want to determine which arguments, should be allowed to be nullable, the @Nullable annotation can be used.



26. Don’t Use Raw Types
Since Java 5, generics were introduced. However, before that Collections (e.g. List) where still part of the language.

With generics it became possible to declare, inside the diamond declaration (), which type a List would be working with. Without a diamond declaration, it would be classified as a raw type.

Because of backwards compatibility these raw types where not removed after java 5’s release. However, regardless of them being part of the language, they should never be used.

Raw types enable the possibility to add unintended objects to the List, which will throw an exception at runtime.


Classes & Interfaces

15. Limit Accessibility To Classes And Members
Generally, any class or member of a class should have the lowest possible access level, which still allows for its functionality to work.

API Example:

Take the case of an externally exposed API, where the interface represents all public accessible methods. Any implementation of this interface should only have public access level on the implemented methods.

The additional members of the implementing class should never be made public. Ideally private or package-private if required for unit testing.

In the case of the exposed API, any publicly available member of the implementation will have to be supported forever, if they have once been published. If members are degraded to a lower access level, it will ruin the API’s backwards compatibility.

Scroll to Top
INTEGU - Cookie-consent

INTEGU uses cookies to personalize your experience and provide traceability for affiliate links. By using the website, you agree to these terms and conditions. To learn more see the privacy policy page.