Why Alibaba Prohibits Certain Java Practices: Logging, Collections, Serialization, and More

The article explains Alibaba's Java Development Manual rules—covering logging APIs, collection initialization, foreach loop modifications, static SimpleDateFormat, string concatenation in loops, serialVersionUID handling, subList usage, inheritance, isSuccess naming, COUNT(*) versus COUNT(col), and thread‑pool creation—providing the rationale behind each prohibition for safer, more efficient backend Java code.

Full-Stack Internet Architecture
Full-Stack Internet Architecture
Full-Stack Internet Architecture
Why Alibaba Prohibits Certain Java Practices: Logging, Collections, Serialization, and More

Alibaba released the Java Development Manual, covering coding conventions, exception logging, unit testing, security, MySQL, project structure, and design guidelines.

1. Logging APIs – Engineers should use a logging facade such as SLF4J with Log4j rather than calling Log4j or Logback APIs directly, to decouple business code from the underlying framework.

2. Collection initialization – Specify initial capacity for collections like HashMap to avoid repeated rehashing; use Guava's

Map<String, String> map = Maps.newHashMapWithExpectedSize(10);

to calculate the optimal size.

3. Modifying collections in foreach loops – The enhanced for‑loop uses an Iterator; modifying the collection directly triggers fail‑fast ConcurrentModificationException. Use an explicit Iterator, a regular for loop, or Stream filtering instead.

4. SimpleDateFormat – Declaring it as static shares the instance across threads, causing thread‑safety issues because it holds mutable state (Calendar). Define it per‑thread or use thread‑safe alternatives.

5. String concatenation in loops – The “+” operator creates a new StringBuilder on each iteration, leading to unnecessary object allocation; prefer a single StringBuilder or String.join.

6. serialVersionUID – Changing this field breaks compatibility between serialized and deserialized classes, causing InvalidClassException; keep it stable unless a deliberate version change is required.

7. subList usage – subList returns a view of the original list; structural changes affect both lists and may throw ConcurrentModificationException. Use a copy when isolation is needed.

8. Inheritance – Inheritance tightly couples subclasses to parent implementations, reducing flexibility; favor composition for better modularity.

9. Variable name isSuccess – Some JSON libraries treat isSuccess as a getter for a boolean property, leading to duplicate fields; rename to success to avoid conflicts.

10. COUNT(*) vs COUNT(col) – COUNT(*) is a SQL‑92 standard optimized by MySQL; counting a column adds a NOT NULL check and is slower.

11. Thread‑pool creation – Using Executors without specifying queue capacity can create unbounded queues, risking OOM; configure bounded queues or use custom ThreadPoolExecutor.

These summaries reflect the author’s personal understanding after studying the manual and illustrate why each rule exists for safer, more efficient backend Java development.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

serializationcoding standardsbackend-developmentthread-pool
Full-Stack Internet Architecture
Written by

Full-Stack Internet Architecture

Introducing full-stack Internet architecture technologies centered on Java

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.