Posts
How To Avoid NullPointerException? 2 - Replace Null by Default Value
- Get link
- X
- Other Apps
HowToAvoidNPE2 How To Avoid NullPointerException? 2 - Replace Null by Default Value We discussed on how to tackle NullPointerException(NPE) in last post, by identifying whether null is allowed. We properly state our assumption and validate not nullable input. We continue on how to eliminate null today. Default instead of null Some Java Class/Interface has good default values: Class Default Value String “” List Collections.emptyList(), new ArrayList<>() Set Collections.emptySet(), new HashSet<>() Map Collections.emptyMap(), new HashMap<>() Array new int[]{}, new Integer[]{}… These Class/Interface can be classified as “Container”. Naturally, “Container” should be empty, instead of null. Initialize the field with default value. For example: public class BankAccount { private Integer accountId ; private String owner = "" ; private BigDecimal balance ; private LocalDate createDate ;
How To Avoid NullPointerException? 1 - Should we allow Null?
- Get link
- X
- Other Apps
HowToAvoidNPE1 How to avoid NullPointerException 1 - Should We Allow Null? NullPointerException(NPE) is the most common type of Exception we face in Java. How can we avoid NPE? Consider the following example: public class BankAccount { private Integer accountId ; private String owner ; private BigDecimal balance ; // Getter Setter } public class BankService { public void transferAmountTo ( BankAccount from , BankAccount to , BigDecimal amount ) { from . setBalance ( from . getBalance ( ) . subtract ( amount ) ) ; to . setBalance ( to . getBalance ( ) . add ( amount ) ) ; } } What will you do when you see NPE when executing transferAmountTo ? Null Check This is almost the first thing we do when we see NPE. public void transferAmountTo ( BankAccount from , BankAccount to , BigDecimal amount ) { if ( from != null ) { if ( to != null ) { if ( from . getBalance ( ) != null ) { if
Migrate from Joda to Java(JSR-310)
- Get link
- X
- Other Apps
Migrate from Joda to Java(JSR-310) So, I recently migrated Joda to Java(JSR-310) in a 12-years-old project. In this article, I will describe what I did, and provide some tips along the way. I will also share some of the lessons I learned from this migration. Why? That is simple, because we want to make our life easier. After migration, the project will benefit from Native support from the ecosystem, for example JPA Build faster with less dependency bug fix/security patch can be received immediately In addition, quoting from Joda Time Joda-Time is the de facto standard date and time library for Java prior to Java SE 8. Users are now asked to migrate to java.time (JSR-310). So if you are working in legacy project using Joda, it is time to consider migrating to JSR-310. How? To begin, like any kind of migration, make sure you have enough test coverage before making any change. If no, it’s time to leave and add more test. Congratulate if you continue to read, I will jus