[BUG][code-analyzer] sfge: List.sort(Comparator) aborts the entry point (API 61 overload not accepted)

Start in ApexListValue.java around lines 305-308, then review ApexValue.java:610 to understand the parameter validation failure. Reproduce with the provided sf code-analyzer command and Apex example; done means sort(Comparator) no longer aborts the entry point and analysis completes without the InternalExecutionError.

Have you tried to resolve this issue yourself first?

• I confirm I have gone through the above steps and still have an issue to report.

Bug Description

Engine: sfge (Salesforce Graph Engine) · Rule: ApexFlsViolation (DevPreview) · Selector: --rule-selector sfge

ApexListValue.apply asserts sort takes zero parameters:

// ApexListValue.java:305-308
} else if (METHOD_SORT.equalsIgnoreCase(methodName)) {
    validateParameterSize(vertex, 0);
    // Intentionally left blank
    // TODO: Does this need to sort?

Apex added List.sort(Comparator<T>) in API 61 (Spring '24). The zero-argument assertion was never updated, so the overload throws at ApexValue.java:610.

List<Account> accs = new List<Account>();
accs.sort(new ByName());

Output / Logs

UnexpectedException: MethodCallExpressionVertex{fullMethodName=accs.sort, ... MethodName=sort}:
com.salesforce.graph.symbols.apex.ApexValue.validateParameterSize(ApexValue.java:610);
com.salesforce.graph.symbols.apex.ApexListValue.apply(ApexListValue.java:306);
com.salesforce.graph.symbols.PathScopeVisitor.handleApexValueMethod(PathScopeVisitor.java:1487); ...

Steps To Reproduce

1. Create an empty SFDX project (sfdx-project.json with a single force-app package directory).
2. Add force-app/main/default/classes/ListSortComparator.cls with the class shown below, plus a standard ListSortComparator.cls-meta.xml (apiVersion 62.0).
3. Add code-analyzer.yml:

   engines:
     sfge:
       java_thread_timeout: 900000
       java_thread_count: 4
   

4. Run:

   sf code-analyzer run --rule-selector sfge --workspace . --config-file code-analyzer.yml
   

5. The run reports an InternalExecutionError for the entry point instead of analysing it. That entry point yields no ApexFlsViolation findings at all, and nothing in the summary indicates coverage was lost.

public with sharing class ListSortComparator {
    public class ByName implements Comparator<Account> {
        public Integer compare(Account a, Account b) { return 0; }
    }
    @AuraEnabled
    public static void run() {
        List<Account> accs = new List<Account>();
        accs.sort(new ByName());
        insert accs;
    }
}

Expected Behavior

sort(Comparator) should be accepted. Suggested fix: validateParameterSizes(vertex, 0, 1). The existing body is already a no-op with a // TODO: Does this need to sort?, so accepting the comparator argument costs nothing beyond the assertion change.

Operating System

macOS 26.5.2

Salesforce CLI Version

@salesforce/cli/2.147.7 darwin-arm64 node-v24.5.0

Code Analyzer Plugin (code-analyzer) Version

code-analyzer 5.15.0

Node Version

v24.5.0

Java Version

openjdk version "11.0.32" 2026-07-21

Python Version

N/A

Additional Context (Screenshots, Files, etc)

One signature / one entry point in our codebase, but Comparator is the modern idiom for sorting in Apex and adoption is only going to grow, so this will get more common rather than less.

Workaround

Fall back to implements Comparable on the element type and call the zero-argument sort(), which sfge accepts.

Urgency

Moderate