Common Java Coding Pitfalls and How to Avoid Them

This article collects a series of typical Java code pitfalls, explains the underlying causes, and provides concrete avoidance methods.

1. Object comparison with Objects.equals

Before JDK 1.7 developers often used the == operator to compare wrapper types (e.g., Short shortValue = (short)12345; ). The compiler automatically unboxes the wrapper and performs a primitive comparison, which yields true . After switching to Objects.equals , the comparison fails because the two arguments have different runtime types ( Short vs Integer ). The article shows the bytecode of both versions and explains why the compiler inserts automatic unboxing for == but not for Objects.equals . Avoidance: keep consistent data types (cast constants to the same primitive type) or let the IDE warn about mismatched types.

2. Ternary‑operator type conversion

When the false branch of a ternary expression returns a Double reference that is null , the compiler still converts the whole expression to the primitive double type, causing a NullPointerException at runtime. Bytecode analysis shows that the compiler inserts a call to Double.doubleValue() on the null operand. Avoidance: avoid ternary expressions that mix arithmetic and wrapper types, or rewrite them as explicit if‑else blocks; prefer primitive types when possible.

3. Generic object assignment

Assigning a List<UserDO> to a PageDataVO<UserVO> field compiles because of raw‑type compatibility, but it silently copies the wrong generic type, potentially exposing sensitive fields. The article recommends using the diamond operator ( new PageDataVO<>(…) ) so the compiler forces type inference and reports an error.

4. BeanUtils property copying

When copying properties from UserDO (generic BaseDO<T> ) to UserVO , the id field is not copied because the generic getter returns Object , which ClassUtils.isAssignable rejects for Long . The fix is to copy the field manually or ensure the generic type is correctly resolved.

5. Set deduplication

Using a HashSet<City> without overriding equals and hashCode does not eliminate duplicate city entries because each City instance has a distinct identity. The article provides proper implementations of equals and hashCode based on the city code, after which duplicates are removed.

6. CGLIB proxy pitfalls

When a Spring service class contains final methods or fields, CGLIB creates a proxy that does not intercept those members. Consequently, setting a field via a proxied method updates the original instance, while reading it through the proxy returns null . The solution is to avoid final on proxied classes/methods, keep the proxy scope minimal, or expose immutable data via static constants or accessor methods.

7. Public field proxy issue

A public mutable field (e.g., public final User superUser ) is not initialized in the CGLIB subclass, leading to NullPointerException when accessed through the proxy. The recommended fixes are: use a static final constant, make the field private with a getter, or follow JavaBean conventions and avoid public instance fields.

Overall, the article emphasizes good coding habits, proper use of IDE warnings, thorough unit testing, and awareness of Java language and Spring framework internals to prevent subtle bugs.