2.4.0.8 release notes

2.4.0.8

  • Issue 2974 - Summer '26 / API v67.0 update
    • Updated the SOAP client for API v67.0.
    • Updated the API version used for primary communication with Salesforce APIs to 67.0.
    • Added 67.0 as an available API version number for configured connections.
    • Updated metadata.xsd based on the API v67.0 Metadata API SOAP WSDL.
    • Updated the OST version number to prompt regeneration for system API changes in Summer '26.
    • Updated the bundled completions?type=apex Tooling REST API response to be based on the API v67.0 REST endpoint.
    • Updated Visualforce, Aura, and LWC components, functions, modules, etc., for Summer '26 changes.
    • Updated the bundled SLDS CSS and SVG icons to 2.30.4.
    • Updated for new org features, standard value set names, metadata XML file type extensions, etc.
    • Updated all integrated API documentation.
    • Usages of SOQL WITH SECURITY_ENFORCED in Apex source files with API version 67.0+ are now flagged as errors with a quick-fix to use WITH USER_MODE instead.
    • Apex classes with API version 66.0+, @InvocableMethod-/@InvocableVariable-annotated members, and parameterized constructors but no no-arg constructor are now flagged as errors with a quick-fix to add a no-arg constructor. Note that these classes are deployed/compiled without errors but yield errors at runtime when used in an invocable context.
    • Added full support for Apex integration tests (developer preview). Apex unit tests and integration tests have been rationalized into a single run configuration type with the same general features as traditionally present for Apex unit tests. There is now a test type discriminator on each run config that acts as an effective filter for the types of tests associated with that run config as one of:
      • Unit - The run config only executes Apex unit tests.
      • Integration - The run config only executes Apex integration tests.
      • Unspecified - Either Apex unit tests or integration tests can be executed by the run config, but due to current API restrictions, only one type of test can be included in a specific execution. If only unit tests or only integration tests are found for the run config when requested for execution, those tests are executed automatically. If both types of tests are found, the user is prompted which to execute with an option to set that as the run config test type going forward.
      Existing Apex unit test run configs are automatically grandfathered as being for unit tests. Context configurations that are based on one type of test, e.g., those for a specific test class or method, are automatically configured for that type. It's possible to change the test type for a run config in the run config editor as long as it's not inherently inferred from the scope of that run config. Note that run configurations for both unit tests and integration tests are called Apex Unit Tests in the IDE's run configuration editor because changing the run config type name to be more general caused issues with existing Apex unit test run configs.

      Note that integration tests do not generate code coverage, so Run with Coverage executors are not available for integration test-specific run configs. If an unspecified-type run config is executed for coverage for integration tests, the user is notified that coverage was not collected and will not be displayed.

      It is also not yet possible to execute integration tests with Apex Execution Runtime / aer via its command-line interface. I've spoken with October Swimmer about this and, once it is possible to execute integration tests via the command-line, I will enable that feature in IC.

    • Added full support for Apex multiline strings:
      • Updated the Apex parser for multiline strings.
      • Added multiline string-specific syntax highlighting that clearly shows the boundaries of multiline string contents even when indented.
      • Added support for formatting of multiline strings. By default, multiline strings are indented at one more than the current statement's indentation level, but they can be aligned with the first column if desired. The Apex formatter option that controls this behavior is Settings | Editor | Code Style | Apex | Tab and indents | Allow multiline strings in first column and is enabled by default.
      • Added support for template-driven multiline strings using the new String.template(Map<String, Object>) method:
        • Template variable references of the form ${name} are highlighted distinctly in multiline strings.
        • Template variable references that resolve to a key in the template map can be navigated. Unfortunately this navigation is currently one-way and doesn't result in selection highlighting or the ability to find usages of template keys. I hope to resolve those limitations shortly.
        • Code completions are offered in template variable references for template map keys.
        • IC includes two new live templates for generation of template-driven multiline strings:
          • mlst - Generates a string variable declaration initialized with a template-driven multiline string, e.g.:
            String str = '''
    <caret>'''
    .template(new Map<String, Object> {

    });
          • mlsti - Same as above but with a language injection comment above the declaration so that the IDE treats the multiline string's contents as being a document in that language, e.g.:
            // language=<languageId>
String str = '''
    <caret>'''
    .template(new Map<String, Object> {

    });
        • I'm also likely going to add a code intention / quick-fix to convert concatenated Apex strings into multiline strings with a template if necessary for non-string literal expression components of the concatenation. That didn't quite fit into this build, but it's on my TODO list.
      • The latter live template demonstrates an incredibly powerful JetBrains IDE feature that's particularly useful with multiline strings (though it also works well with concatenated single-line strings), language injections. Given that one of the primary use cases for multiline strings is to host content in other languages such as SOQL, SOSL, JSON, and XML, it's exceptionally useful to be able to leverage the IDE's first-class support for the associated language when working with that content. The easiest way to do this in a durable manner is by adding a line comment of the form:
        // language=<languageId>
        immediately preceding the multiline string or associated declaration. The IDE provides code completions for available language IDs. Note that the language ID for SOQL and SOSL is apex.

  • Issue 2973 - Fixed an issue that could prevent the new metadata format project wizard from displaying properly.