Feature/multiple breaks

[r4m-juan]

No description provided.

[github-actions]

Uh Oh

It seems that your pull request doesn't pass conventional commit validation

Don't worry! This guide will help you to fix this issue and avoid it in future!

• Please check conventional commit specification and tips how to write perfect messages
• If you are using IntelliJ IDEA, please take a look at special plugin
• In order to fix your commit messages you should create new pull request from another branch, force push is not allowed. You can do it in IntelliJ IDEA using this guide or using git cli and that guide. This pull request will be closed automatically.

[github-actions]

Gemini AI Code Risk & Compatibility Analysis

Status: [OK] Analysis completed successfully

Files analyzed:

• src/main/java/com/route4me/sdk/examples/MultipleBreaksOptimization.java
• src/main/java/com/route4me/sdk/services/routing/Break.java
• src/main/java/com/route4me/sdk/services/routing/Parameters.java

Analysis Results

Here is an analysis of the provided Java code changes, categorized by the requested areas of concern:

Security and performance risks

• Severity: Medium
  • Issue: In Break.java, the modeParams field is defined as an array (private int[] modeParams;). When combined with Lombok's @Data annotation, this generates a getter and setter that return and accept direct references to the mutable array. This breaks encapsulation, potentially allowing external or malicious code to modify the internal state of the Break object unexpectedly (known as malicious object reference exposure).
  • Suggestion: Change the field type to a List<Integer>, or manually implement the getter and setter for modeParams to return and store a clone of the array (e.g., return modeParams != null ? modeParams.clone() : null;).

Null safety issues

• Severity: High
  • Issue: In MultipleBreaksOptimization.java, the execution state is accessed via responseObject.getState().intValue(). If the API response does not include a state, getState() may return null, causing an immediate NullPointerException when .intValue() is called.
  • Suggestion: Add a null safety check before unboxing:

  Number state = responseObject.getState();
  if (state != null) {
      System.out.println("State: " + OptimizationState.get(state.intValue()));
  }

Checked exception handling concerns

• Severity: Low
  • Issue: In MultipleBreaksOptimization.java, the checked APIException is caught and handled solely by calling e.printStackTrace();.
  • Suggestion: Although this is example code, it is best practice to avoid printStackTrace(). Use a proper logging framework (like Log4j2, which appears available in your resources) to log exceptions, encouraging good habits for developers referencing this example.

Deprecated API usage

• Severity: Low
  • Issue: No clear deprecated API usage is introduced in these specific diff changes.

Coding standard violations

• Severity: High
  • Issue: Invalid annotation syntax. Throughout Break.java and Parameters.java, annotations have been replaced with literal file paths (e.g., @src/main/java/com/route4me/sdk/services/territories/TerritoryData.java instead of @Data, and @...QueryParameter.java("mode") instead of @QueryParameter("mode")). This will cause compilation failures.
  • Suggestion: Revert the file paths back to their proper Java annotations.
• Severity: Medium
  • Issue: In Parameters.java, the field private List<Break> breaks; is annotated with @QueryParameter("breaks"). If your custom QueryConverter does not contain logic to serialize complex collections of objects into a URL query string, this could result in runtime errors or malformed requests.
  • Suggestion: Verify that the query string serialization supports complex List<Object> types. If breaks are only intended for the JSON request body, remove the @QueryParameter annotation entirely.
• Severity: Low
  • Issue: Missing diamond operator <> when instantiating generic collections in MultipleBreaksOptimization.java (e.g., new ArrayList<Break>()).
  • Suggestion: Use the diamond operator (new ArrayList<>()) to reduce verbosity.
• Severity: Low
  • Issue: Code duplication when setting up Break objects in the example file.
  • Suggestion: Extract the break creation logic into a private helper method to keep the main method clean and DRY.

Potential backward compatibility risks

• Severity: Low
  • Issue: Adding the new breaks property to Parameters.java and creating the Break class extends the API payload. Adding fields is generally safe and backward-compatible.
  • Suggestion: Ensure that the API backend defaults to ignoring null values for the new breaks property if it is absent in older client implementations, ensuring older code behaves without side effects.