Common Configuration and Code Issues in a New Java Backend Project

On his first day the new Java backend developer discovered duplicated internal and external configuration files causing NullPointerExceptions, hard‑coded role strings, mixed System.out and logger calls, missing manager review leading to DB mismatches, arbitrary production database edits, and Maven pom‑type dependency errors, prompting a shift to unified application.yml settings, JVM‑specified config locations, consistent logging, and stricter coding standards.

Java Tech Enthusiast
Java Tech Enthusiast
Java Tech Enthusiast
Common Configuration and Code Issues in a New Java Backend Project

On the first day at a new company the author was immediately assigned tasks, exposing a series of configuration and code problems.

Issue 1: The project reads two configuration files—one inside WEB-INF and one external—leading to duplicated settings and confusion about which values take precedence.

Example code that sets a property: prop_c.setProperty(key, value); When the external value is missing, a NullPointerException is thrown. The underlying Properties implementation uses a Hashtable.

Another snippet shows a synchronized put method that checks for null values:

public synchronized V put(K key, V value) {<br/>    // Make sure the value is not null<br/>    if (value == null) {<br/>        throw new NullPointerException();<br/>    }<br/>}

Issue 2: Many parameters are hard‑coded in the source, making future changes labor‑intensive. Example: role.haveRole("ADMIN_USE") Issue 3: Logging is inconsistent, mixing System.out.println with proper logger calls, and sometimes catching multiple exceptions unnecessarily.

Issue 4: Lack of technical manager review leads to mismatched production and local code, causing database synchronization problems.

Issue 5: Arbitrary changes to the production database rely solely on developers' discipline.

Issue 6: Maven dependency problems arise from using a pom type without an actual JAR. The fix often involves adding: <type>pom</type> Solutions: For new or upgraded projects, keep configuration inside application.yml (or application.properties) and avoid external files unless necessary. In production, specify the config location via the JVM command line, e.g.:

nohup java -Dfile.encoding=UTF-8 -Dspring.config.location=server/src/main/config/application.properties -jar xxx.jar &

Adopt consistent coding standards, avoid modifying existing source unless refactoring, and rely on proper logging and configuration management.

"I was once a happy student with lofty ideals, until I faced mountain after mountain and pit after pit..."

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.

javabackend-developmentConfigurationspringmaven
Java Tech Enthusiast
Written by

Java Tech Enthusiast

Sharing computer programming language knowledge, focusing on Java fundamentals, data structures, related tools, Spring Cloud, IntelliJ IDEA... Book giveaways, red‑packet rewards and other perks await!

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.