SONARJAVA-6298 Modify S2143 to also suggest using java.time instead of Joda-Time

[NoemieBenard]

No description provided.

[hashicorp-vault-sonar-prod]

SONARJAVA-6298

[sonar-review-alpha]

Summary

S2143 Rule Enhancement: String-Based Import Detection

This PR modifies the "Use Java 8 Date and Time API instead" rule to detect problematic imports directly via string parsing, rather than relying solely on semantic analysis of method invocations and constructors.

Key Changes:

• The check now analyzes import statements and flags imports of Joda-Time (org.joda.time.*) and legacy Java date/time classes (Date, Calendar, java.sql.Date, etc.)
• Switched from semantic-based detection to syntactic import analysis using ExpressionsHelper
• Added new test case for wildcard imports and a test mode that verifies the check works without semantic information
• Integration test baselines significantly expanded, reflecting the increased coverage (more files now flagged due to import-level detection)

What reviewers should know

Where to Start

Read the core logic change in java-checks/src/main/java/org/sonar/java/checks/DateAndTimesCheck.java:

• The new visitNode() override handles import analysis (lines ~44–52)
• KNOWN_JAVA_UTIL_DATE_TIME_CLASSES set defines what legacy classes trigger the rule
• The check still inherits semantic detection from AbstractMethodDetection for method calls/constructors

Key Implementation Details

1. Dual Detection: The rule now detects issues two ways:

   • Import statements (new) — reported immediately when Joda-Time or legacy java.util/java.sql date classes are imported
   • Method invocations/constructors (existing) — still detected via parent class semantic matching

2. String Parsing Approach: Uses ExpressionsHelper.concatenate() to extract the fully qualified import name from the syntax tree, then checks it against known problematic patterns. No semantic symbol resolution needed.

3. Known Limitation: Wildcard imports like import java.util.* are not detected by the rule. See DateAndTimesCheckWildcardImport.java for expected behavior.

What the Baseline Changes Mean

The integration test files (.json baselines) show significantly more violations because:

• Previously only flagged actual usage (e.g., new Date(), Calendar.getInstance())
• Now also flags the imports themselves, increasing detection count per file
• This is expected and correct behavior for the new approach

Testing

The test suite now includes:

• Standard file test (with semantic analysis)
• New test_wildcard_import() — verifies wildcard imports don't trigger false positives
• New test_without_semantic() — confirms the rule works in non-semantic mode (string parsing only)

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[aurelien-coet-sonarsource]

Should we consider reporting issues for the old date and time API on imports of Date and Calendar rather than on their uses, to be consistent with what we do on JodaTime ?

[aurelien-coet-sonarsource]

The current implementation for imports LGTM, but we should probably still report an issue on uses or insantiations of Date and Calendar when they are imported via a wildcard import. For example, we would report an issue for the rule on a call to new Date() when the class is imported with import java.util.*:

import java.util.*;

class ShouldRaiseOnUse {
    void foo() {
        Date now = new Date(); // Noncompliant ...
    }
}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[aurelien-coet-sonarsource]

We should probably not raise an issue twice when an import of the form import java.util.Date is found and the class is instantiated later. Instead, when Date and related classes are explicitly imported, the issue should only be raised on the import. It is only in the case of a wildcard import that the issue would be raised on the use. This could be done with a flag recording if an "explicit" import was already found in the implementatoin. WDYT ?

[aurelien-coet-sonarsource]

I don't think an issue should be raised here. In the case where these classes are explicitly imported (i.e. not with a wildcard import), we already raise the issue on the import, so it is redundant to report it again on the use.