SONARJAVA-6786 Implement new rule S9346: Integer values should not be cast to long for use as timestamps

[romainbrenguier]

Detect 32-bit or smaller integer values (int, short, byte, char) passed as arguments to timestamp-consuming APIs (Date, Timestamp, Instant, Calendar), where the narrow type causes overflow or data corruption.

[hashicorp-vault-sonar-prod]

SONARJAVA-6786

[gitar-bot]

⚠️ Bug: Rule misses documented case: int cast stored in long variable

The canonical Noncompliant example in S9346.html stores (long) timestamp in a long variable and then passes that variable to new Date(epochMillis). The implementation's checkArgument only inspects the direct argument at the call site (skipping parentheses and unwrapping a single TypeCast), so a long-typed variable argument yields a non-narrow type and is never reported. The primary documented pattern is therefore a false negative and is not covered by the sample test file. Either narrow the documentation example to match what the check detects (cast/int directly in the call), or extend the check to trace the argument's initializer when it is a local variable assigned from a narrow-int cast, and add a corresponding test case.

_{Was this helpful? React with 👍 / 👎}

[github-actions]

❌ Ruling needs updating. A fix PR has been created: #5958

Please review and merge it into your branch.

[github-actions]

Ruling Diff Summary

Detected changes in 1 rule files: 0 issues removed, 2 issues added.

S9346 (java) on eclipse-jetty - 0 issues removed, 2 issues added - new ruling file

Added jetty-util-ajax/src/test/java/org/eclipse/jetty/util/ajax/JSONTest.java (line 366)

(source file not found at this revision: jetty-util-ajax/src/test/java/org/eclipse/jetty/util/ajax/JSONTest.java)

Added jetty-util-ajax/src/test/java/org/eclipse/jetty/util/ajax/JSONTest.java (line 433)

(source file not found at this revision: jetty-util-ajax/src/test/java/org/eclipse/jetty/util/ajax/JSONTest.java)

[gitar-bot]

Code Review ⚠️ Changes requested 1 resolved / 2 findings

Implements new SonarJava rule S9346 to detect narrow integer values passed to timestamp APIs, but the implementation misses the documented canonical case where an int cast is stored in a long variable.

⚠️ Bug: Rule misses documented case: int cast stored in long variable

📄 java-checks/src/main/java/org/sonar/java/checks/IntegerToLongTimestampCastCheck.java:80-92 📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S9346.html:14-18

The canonical Noncompliant example in S9346.html stores (long) timestamp in a long variable and then passes that variable to new Date(epochMillis). The implementation's checkArgument only inspects the direct argument at the call site (skipping parentheses and unwrapping a single TypeCast), so a long-typed variable argument yields a non-narrow type and is never reported. The primary documented pattern is therefore a false negative and is not covered by the sample test file. Either narrow the documentation example to match what the check detects (cast/int directly in the call), or extend the check to trace the argument's initializer when it is a local variable assigned from a narrow-int cast, and add a corresponding test case.

✅ 1 resolved

✅ Edge Case: Rule flags legitimate int/long-literal timestamps causing noise

📄 java-checks/src/main/java/org/sonar/java/checks/IntegerToLongTimestampCastCheck.java:80-94 📄 java-checks-test-sources/default/src/main/java/checks/IntegerToLongTimestampCastCheckSample.java:75-77
The check reports any narrow-int argument including plain literals such as new Date(0) and int constants that represent valid timestamps within the int range (e.g. seconds fitting before 2038). In real codebases new Date(0) (epoch) and small constants are common and intentional, so this may generate a high volume of false positives. Consider excluding constant/literal arguments or those provably within a safe range, or documenting this behavior explicitly in the RSPEC.

🤖 Prompt for agents

Code Review: Implements new SonarJava rule S9346 to detect narrow integer values passed to timestamp APIs, but the implementation misses the documented canonical case where an int cast is stored in a long variable.

1. ⚠️ Bug: Rule misses documented case: int cast stored in long variable
   Files: java-checks/src/main/java/org/sonar/java/checks/IntegerToLongTimestampCastCheck.java:80-92, sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S9346.html:14-18

   The canonical Noncompliant example in S9346.html stores `(long) timestamp` in a `long` variable and then passes that variable to `new Date(epochMillis)`. The implementation's `checkArgument` only inspects the direct argument at the call site (skipping parentheses and unwrapping a single TypeCast), so a `long`-typed variable argument yields a non-narrow type and is never reported. The primary documented pattern is therefore a false negative and is not covered by the sample test file. Either narrow the documentation example to match what the check detects (cast/int directly in the call), or extend the check to trace the argument's initializer when it is a local variable assigned from a narrow-int cast, and add a corresponding test case.

Implementation Status ✅ 1 / 1 issues implemented

✅ SONARJAVA-6786 — 1 / 1 objectives

The PR successfully implements rule S9346 (Integer values should not be cast to long for use as timestamps) with appropriate check logic, tests, metadata, and documentation.

✅ 1 complete

• ✅ Implement new rule S9346: Integer values should not be cast to long for use as timestamps

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.
Unblock → Override a blocking verdict and allow merging.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact	Unblock
gitar auto-apply:on	gitar display:verbose	gitar unblock

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

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

See analysis details on SonarQube