[et_pb_section fb_built=”1″ admin_label=”Hero” _builder_version=”4.27.5″ _module_preset=”default” custom_padding=”0vw||80px||false|false” locked=”off” collapsed=”on” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_row _builder_version=”4.18.0″ _module_preset=”5138c454-be54-4233-bd3b-f8e6a8747976″ global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.18.0″ _module_preset=”73121f80-a3ef-4484-8763-c3f18e3c56d2″ global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”SAP Commerce” _builder_version=”4.27.5″ _module_preset=”f0c675ea-2574-4d0e-b725-30f8550a8550″ title_level=”h4″ title_font=”IBM Plex Sans|IBM Plex Sans Condensed_weight||on|||||” title_text_color=”#1d3557″ title_font_size=”14px” title_letter_spacing=”1px” title_line_height=”1.4em” custom_margin=”||10px||false|false” locked=”off” global_colors_info=”{%22#1d3557%22:%91%22title_text_color%22%93}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_heading title=”Spring Framework 6 and Java 21 Migration for SAP Commerce Cloud” _builder_version=”4.27.5″ _module_preset=”ddeb8c09-9078-4424-bc15-2efb6572e28e” title_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_post_title title=”off” meta=”off” featured_image=”on” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_post_title][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
SAP Commerce Cloud’s move to Spring Framework 6 and Java 21 is one of the most impactful technical changes to hit the platform in years. Unlike a typical patch release that you can absorb over a sprint, this migration touches the foundations: the dependency injection framework, the servlet API, the security layer, and the JVM itself. If you have custom extensions (and every real-world SAP Commerce implementation does), you have work to do.<\/p>\n
This article is written for developers and architects who need to plan and execute this migration. We will cover what changes, what breaks, how to fix it, and how to test it. This is a technical guide, not a management overview.<\/p>\n
[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Why This Is Happening” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
SAP Commerce Cloud has historically run on Spring Framework 5.x and Java 17 (or earlier). The broader Java ecosystem has moved forward substantially:<\/p>\n
javax<\/code> namespace with jakarta<\/code>, affecting the Servlet API, JPA, Bean Validation, and numerous other specifications.<\/li>\n<\/ul>\nSAP is aligning Commerce Cloud with these ecosystem shifts. The specific version and timeline depends on your Commerce Cloud release train, but the direction is clear: Spring 6 and Java 21 are the new baseline, and custom code that does not comply will not compile.<\/p>\n
[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”The Big Three Changes” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
Before diving into step-by-step migration, understand the three categories of changes that will affect your codebase.<\/p>\n
1. Jakarta EE Namespace Migration (javax to jakarta)<\/h3>\n
This is the most mechanically pervasive change. The Jakarta EE community renamed the package namespace from javax.*<\/code> to jakarta.*<\/code> starting with Jakarta EE 9. This affects:<\/p>\n\n- Servlet API:<\/strong>
javax.servlet.*<\/code> becomes jakarta.servlet.*<\/code><\/li>\n- JPA\/Persistence:<\/strong>
javax.persistence.*<\/code> becomes jakarta.persistence.*<\/code><\/li>\n- Bean Validation:<\/strong>
javax.validation.*<\/code> becomes jakarta.validation.*<\/code><\/li>\n- Annotations:<\/strong>
javax.annotation.*<\/code> becomes jakarta.annotation.*<\/code><\/li>\n- Mail:<\/strong>
javax.mail.*<\/code> becomes jakarta.mail.*<\/code><\/li>\n- WebSocket:<\/strong>
javax.websocket.*<\/code> becomes jakarta.websocket.*<\/code><\/li>\n- JSON Processing\/Binding:<\/strong>
javax.json.*<\/code> becomes jakarta.json.*<\/code><\/li>\n<\/ul>\nImportantly, not everything under javax<\/code> changed. javax.sql.*<\/code>, javax.crypto.*<\/code>, javax.net.*<\/code>, and other packages that are part of the core JDK (not Jakarta EE) remain unchanged.<\/p>\nThe sheer number of files affected can be daunting, but the change itself is mechanical. The challenge is finding every occurrence, including in configuration files, XML descriptors, and string literals, not just Java imports.<\/p>\n
2. Spring Framework 6 API Changes<\/h3>\n
Beyond the namespace migration, Spring 6 introduces its own set of breaking changes:<\/p>\n
Spring Security overhaul.<\/strong> If you have custom security configurations (and most SAP Commerce implementations do), this is where you will spend significant time. Key changes:<\/p>\n\nWebSecurityConfigurerAdapter<\/code> is removed. Security configuration must use the component-based SecurityFilterChain<\/code> bean approach.<\/li>\nantMatchers()<\/code>, mvcMatchers()<\/code>, and regexMatchers()<\/code> are replaced by requestMatchers()<\/code>.<\/li>\n- CSRF configuration changes. The default behavior is stricter, and the configuration API has changed.<\/li>\n
- OAuth2 client and resource server configurations have been restructured.<\/li>\n<\/ul>\n
Removed deprecated APIs.<\/strong> Spring 6 removes APIs that were deprecated in Spring 5. If you ignored deprecation warnings (most teams do), those warnings are now compilation errors. Common casualties:<\/p>\n\nRestTemplate<\/code> is not removed but is in maintenance mode. Spring recommends WebClient<\/code> or the new RestClient<\/code> for new code.<\/li>\n- Various
org.springframework.web.servlet.mvc.Controller<\/code> methods have changed signatures.<\/li>\nAsyncRestTemplate<\/code> is removed entirely. Use WebClient<\/code> instead.<\/li>\n<\/ul>\nHTTP interface changes.<\/strong> Spring 6 requires Servlet 6.0+ (part of the Jakarta EE shift). Filter chains, interceptors, and custom DispatcherServlet<\/code> configurations may need adjustment.<\/p>\n3. Java 21 Language and Runtime Changes<\/h3>\n
Java 21 is generally backward-compatible with Java 17 code, but there are breaking changes and new capabilities to be aware of:<\/p>\n
Removed APIs and features:<\/strong><\/p>\n\n- Security Manager is deprecated for removal. If any of your code or dependencies use
System.setSecurityManager()<\/code> or security policy files, those need to be reworked.<\/li>\n- Several
java.lang<\/code> and java.util<\/code> methods deprecated in earlier versions are now removed.<\/li>\n- The default garbage collector behavior has changed (more on this in the performance section).<\/li>\n<\/ul>\n
New capabilities worth leveraging:<\/strong><\/p>\n\n- Virtual threads (Project Loom):<\/strong> Lightweight threads that can dramatically improve throughput for I\/O-bound operations. Relevant for integration-heavy commerce platforms.<\/li>\n
- Pattern matching for switch:<\/strong> Cleaner code for type-checking and dispatching.<\/li>\n
- Record patterns:<\/strong> Useful for DTOs and value objects.<\/li>\n
- Sequenced collections:<\/strong> New interfaces (
SequencedCollection<\/code>, SequencedSet<\/code>, SequencedMap<\/code>) that provide uniform access to first\/last elements.<\/li>\n<\/ul>\nYou do not have to adopt new Java 21 features during the migration. Focus first on making existing code compile and run correctly. Adopt new features in subsequent iterations.<\/p>\n
[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Step-by-Step Migration Approach” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
Step 1: Assess Your Custom Code Surface Area<\/h3>\n
Before changing any code, understand what you are dealing with. Run these assessments across your custom extensions:<\/p>\n
Count namespace occurrences:<\/strong><\/p>\n# Count javax imports that need migration\ngrep -rn "import javax\\.\\(servlet\\|persistence\\|validation\\|annotation\\|mail\\|websocket\\|json\\)" \\\n --include="*.java" your-extensions\/ | wc -l\n\n# Count Spring Security adapter usage\ngrep -rn "WebSecurityConfigurerAdapter\\|antMatchers\\|mvcMatchers\\|regexMatchers" \\\n --include="*.java" your-extensions\/ | wc -l\n\n# Count deprecated Spring API usage\ngrep -rn "AsyncRestTemplate\\|org\\.springframework\\..*deprecated" \\\n --include="*.java" your-extensions\/ | wc -l\n<\/code><\/pre>\nCheck XML and properties files:<\/strong><\/p>\n# Check Spring XML configurations for affected classes\ngrep -rn "javax\\.\\(servlet\\|persistence\\|validation\\)" \\\n --include="*.xml" --include="*.properties" your-extensions\/\n<\/code><\/pre>\nReview third-party dependencies:<\/strong><\/p>\nEvery JAR you bring into your SAP Commerce extensions needs to be compatible with Jakarta EE 10+ and Java 21. Create a dependency inventory and check each one for a compatible version. Common problem areas:<\/p>\n
\n- Older versions of Guava, Apache Commons, Jackson, Gson<\/li>\n
- Legacy SOAP client libraries<\/li>\n
- Older database drivers<\/li>\n
- Testing frameworks (JUnit 4 code may need updates for the new Spring Test context)<\/li>\n<\/ul>\n
Step 2: Update Third-Party Dependencies First<\/h3>\n
Address your dependency chain before touching your own code. This is counterintuitive (most teams want to start with their own code), but dependency issues will block your compilation anyway, and resolving them first gives you a clean baseline.<\/p>\n
For each dependency:<\/p>\n
\n- Check the latest version that supports Jakarta EE 9+ and Java 21<\/li>\n
- Review the changelog for breaking changes<\/li>\n
- Update the version in your build configuration<\/li>\n
- Resolve any immediate compilation issues from the dependency update<\/li>\n<\/ol>\n
Common dependency updates:<\/p>\n
\n\n\nLibrary<\/th>\n Old Version (typical)<\/th>\n New Version (Jakarta-compatible)<\/th>\n<\/tr>\n<\/thead>\n \n\nJackson<\/td>\n 2.13.x<\/td>\n 2.17.x+<\/td>\n<\/tr>\n \nHibernate Validator<\/td>\n 6.x<\/td>\n 8.x+<\/td>\n<\/tr>\n \nEhCache<\/td>\n 2.x<\/td>\n 3.x (or switch to JCache)<\/td>\n<\/tr>\n \nApache HttpClient<\/td>\n 4.x<\/td>\n 5.x<\/td>\n<\/tr>\n \nLombok<\/td>\n 1.18.24<\/td>\n 1.18.32+<\/td>\n<\/tr>\n \nJUnit<\/td>\n 4.x \/ 5.8<\/td>\n 5.10+<\/td>\n<\/tr>\n \nMockito<\/td>\n 4.x<\/td>\n 5.x+<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nPay special attention to Hibernate. If you have custom JPA\/Hibernate code (outside the SAP Commerce Type System), the migration from Hibernate 5 to Hibernate 6 is substantial and involves more than just namespace changes.<\/p>\n
Step 3: Perform the Namespace Migration<\/h3>\n
With dependencies updated, tackle the javax<\/code> to jakarta<\/code> namespace change in your custom code.<\/p>\nAutomated approach:<\/strong> Use OpenRewrite, which has a recipe specifically for Jakarta EE migration:<\/p>\n# Using OpenRewrite Gradle plugin\n.\/gradlew rewriteRun -Drewrite.activeRecipe=org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta\n<\/code><\/pre>\nIf your SAP Commerce build does not integrate easily with OpenRewrite (many do not due to the custom Ant-based build), you can use IntelliJ IDEA’s migration tool or a targeted find-and-replace approach:<\/p>\n
# Manual approach - careful, ordered replacements\n# Do these one at a time and verify compilation after each\n\nfind your-extensions\/ -name "*.java" -exec sed -i '' \\\n 's\/javax\\.servlet\/jakarta.servlet\/g' {} +\n\nfind your-extensions\/ -name "*.java" -exec sed -i '' \\\n 's\/javax\\.persistence\/jakarta.persistence\/g' {} +\n\nfind your-extensions\/ -name "*.java" -exec sed -i '' \\\n 's\/javax\\.validation\/jakarta.validation\/g' {} +\n\nfind your-extensions\/ -name "*.java" -exec sed -i '' \\\n 's\/javax\\.annotation\\.\\(PostConstruct\\|PreDestroy\\|Resource\\|Generated\\|Priority\\)\/jakarta.annotation.\\1\/g' {} +\n<\/code><\/pre>\nDo not blindly replace all javax.*<\/code>.<\/strong> Remember that javax.sql<\/code>, javax.crypto<\/code>, javax.net<\/code>, and JDK-provided packages stay as javax<\/code>. This is the most common mistake in automated migrations.<\/p>\nAlso check:<\/p>\n
\n- web.xml files:<\/strong> Servlet filter and listener class references<\/li>\n
- Spring XML configurations:<\/strong> Bean class references that use
javax<\/code> types<\/li>\n- properties files:<\/strong> Any property values that reference
javax<\/code> classes<\/li>\n- ImpEx files:<\/strong> Unlikely but check if any ImpEx scripts reference Java types<\/li>\n<\/ul>\n
Step 4: Migrate Spring Security Configuration<\/h3>\n
If you have custom Spring Security configurations (most SAP Commerce implementations customize authentication, authorization, or CSRF handling), this step requires careful manual work.<\/p>\n
Before (Spring Security 5):<\/strong><\/p>\n@Configuration\n@EnableWebSecurity\npublic class CustomSecurityConfig extends WebSecurityConfigurerAdapter {\n\n @Override\n protected void configure(HttpSecurity http) throws Exception {\n http\n .authorizeRequests()\n .antMatchers("\/api\/public\/**").permitAll()\n .antMatchers("\/api\/admin\/**").hasRole("ADMIN")\n .anyRequest().authenticated()\n .and()\n .csrf()\n .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());\n }\n}\n<\/code><\/pre>\nAfter (Spring Security 6):<\/strong><\/p>\n@Configuration\n@EnableWebSecurity\npublic class CustomSecurityConfig {\n\n @Bean\n public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {\n http\n .authorizeHttpRequests(auth -> auth\n .requestMatchers("\/api\/public\/**").permitAll()\n .requestMatchers("\/api\/admin\/**").hasRole("ADMIN")\n .anyRequest().authenticated()\n )\n .csrf(csrf -> csrf\n .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())\n );\n return http.build();\n }\n}\n<\/code><\/pre>\nKey changes to note:<\/p>\n
\n- No more extending
WebSecurityConfigurerAdapter<\/code><\/li>\n- Configuration uses lambda DSL (the
.and()<\/code> chaining pattern is deprecated)<\/li>\nauthorizeRequests()<\/code> becomes authorizeHttpRequests()<\/code><\/li>\nantMatchers()<\/code> becomes requestMatchers()<\/code><\/li>\n- CSRF, CORS, and other security configurations use lambda-style configuration<\/li>\n<\/ul>\n
If you have custom AuthenticationProvider<\/code>, UserDetailsService<\/code>, or Filter<\/code> implementations, review them for compatibility. The core contracts are mostly the same, but some edge cases in how filters are ordered and how authentication events are published have changed.<\/p>\nStep 5: Fix Remaining Compilation Errors<\/h3>\n
After the namespace migration and Spring Security update, attempt a full build. Collect all remaining compilation errors and address them systematically.<\/p>\n
Common issues at this stage:<\/p>\n
\n- Removed Spring APIs:<\/strong> Replace with the recommended alternatives (check Spring’s migration guide for each removed class\/method)<\/li>\n
- Type inference changes in Java 21:<\/strong> Rare, but some generic type inference edge cases behave differently<\/li>\n
- Reflection access:<\/strong> Java 21 is stricter about reflective access to internal JDK APIs. If you see
InaccessibleObjectException<\/code>, you need to add --add-opens<\/code> JVM flags or (better) stop accessing internal APIs<\/li>\n- Classpath vs module path:<\/strong> While SAP Commerce does not fully embrace JPMS modules, some libraries now ship as modules. Classpath conflicts may surface differently<\/li>\n<\/ul>\n
Step 6: Update Build Configuration<\/h3>\n
Your build system configuration needs updates for Java 21:<\/p>\n
JVM flags:<\/strong> Java 21 may require additional --add-opens<\/code> flags for frameworks that use deep reflection (Hibernate, Spring, serialization libraries). SAP typically documents the required flags for each Commerce release.<\/p>\nCompiler settings:<\/strong> Ensure your build targets Java 21:<\/p>\n# In your build configuration\njava.source=21\njava.target=21\n<\/code><\/pre>\nGradle\/Ant updates:<\/strong> If you use Gradle for any part of your build, ensure you are on Gradle 8.5+ (required for full Java 21 support). For the Ant-based Commerce build, follow SAP’s documentation for the specific version requirements.<\/p>\nTest frameworks:<\/strong> Ensure your test runner and assertion libraries are compatible. JUnit 5.10+ and Mockito 5.x+ are the safe choices for Java 21.<\/p>\nStep 7: Testing Strategy<\/h3>\n
Migration testing has three layers, and you need all of them.<\/p>\n
Layer 1: Compilation and Unit Tests<\/strong><\/p>\nThe first gate is simply getting the code to compile and unit tests to pass. Expect some test failures due to:<\/p>\n
\n- Mocking framework changes (Mockito 5 has stricter defaults about mocking final classes)<\/li>\n
- Spring Test context changes (how test application contexts are initialized)<\/li>\n
- Assertion library compatibility<\/li>\n<\/ul>\n
Fix these methodically. Do not skip failing tests – they exist for a reason.<\/p>\n
Layer 2: Integration Tests<\/strong><\/p>\nSAP Commerce-specific integration tests (those extending ServicelayerTransactionalTest<\/code> or similar base classes) verify that your code works within the Commerce runtime. These tests are critical because they exercise the actual Spring context, type system, and service layer.<\/p>\nRun these in a CCv2 development environment or a local Commerce instance running on Java 21. Pay special attention to:<\/p>\n
\n- Service layer injection (Spring context must resolve all beans correctly)<\/li>\n
- Interceptor chains (model interceptors, event listeners)<\/li>\n
- Cron job execution<\/li>\n
- ImpEx import\/export<\/li>\n<\/ul>\n
Layer 3: End-to-End Functional Tests<\/strong><\/p>\nOnce unit and integration tests pass, run your full regression suite. Key areas to validate:<\/p>\n
\n- Checkout flow (the most integration-heavy path)<\/li>\n
- Backoffice operations (SmartEdit, Product Cockpit, etc.)<\/li>\n
- API endpoints (OCC REST API responses)<\/li>\n
- Search and indexing (Solr integration)<\/li>\n
- Background processes (order processing, data sync jobs)<\/li>\n<\/ul>\n
Step 8: Performance Validation<\/h3>\n
Java 21 brings performance improvements, but your specific workload may behave differently. Validate before go-live.<\/p>\n
Garbage Collection:<\/strong> Java 21’s default GC (G1) has received significant improvements. If you were using G1 on Java 17, you should see modest throughput improvements. If you were using ZGC or Shenandoah for low-latency requirements, both are more mature in Java 21.<\/p>\nReview your GC configuration:<\/p>\n
# Common GC flags to review and adjust for Java 21\n-XX:+UseG1GC\n-XX:MaxGCPauseMillis=200\n-XX:G1HeapRegionSize=16m\n-XX:InitiatingHeapOccupancyPercent=45\n<\/code><\/pre>\nJava 21’s G1 improvements may allow you to relax some of these tuning parameters. Run load tests with your current settings first, then experiment.<\/p>\n
Virtual Threads:<\/strong> Java 21’s virtual threads (from Project Loom) are a significant opportunity for I\/O-bound workloads, which describes most e-commerce platforms. A typical product page load involves database queries, cache lookups, Solr searches, and potentially external API calls, all I\/O operations that block platform threads.<\/p>\nVirtual threads allow you to use Executors.newVirtualThreadPerTaskExecutor()<\/code> instead of traditional thread pools. The JVM handles scheduling with dramatically lower overhead per thread. For integration-heavy flows (order processing, inventory sync), this can significantly improve throughput without increasing hardware.<\/p>\nHowever, do not adopt virtual threads during the initial migration. Get everything working on platform threads first. Virtual thread adoption is an optimization to pursue after the migration is stable.<\/p>\n
Startup time:<\/strong> Java 21 with Spring 6 may have different startup characteristics. Measure cold start and warm-up times in your CCv2 environments, as this affects deployment and scaling behavior.<\/p>\n[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Dependency Audit Checklist” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
Run through this checklist for every third-party dependency in your custom extensions:<\/p>\n
\n- [ ] Latest version supports Jakarta EE 9+ namespace?<\/li>\n
- [ ] Latest version supports Java 21?<\/li>\n
- [ ] Breaking changes between your current version and the Jakarta-compatible version documented?<\/li>\n
- [ ] Transitive dependencies also compatible? (a common trap: your library is compatible, but it pulls in an older version of something that is not)<\/li>\n
- [ ] License unchanged in the new version?<\/li>\n
- [ ] If no compatible version exists: is there an alternative library? Can you inline the functionality?<\/li>\n<\/ul>\n
[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Timeline and Effort Estimates” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
Based on our experience with SAP Commerce implementations of varying complexity:<\/p>\n
\n\n\nCodebase Size<\/th>\n Custom Extensions<\/th>\n Estimated Effort<\/th>\n Calendar Time<\/th>\n<\/tr>\n<\/thead>\n \n\nSmall<\/td>\n < 10 extensions, < 50K LoC<\/td>\n 2-4 developer-weeks<\/td>\n 4-6 weeks<\/td>\n<\/tr>\n \nMedium<\/td>\n 10-25 extensions, 50-150K LoC<\/td>\n 6-12 developer-weeks<\/td>\n 8-14 weeks<\/td>\n<\/tr>\n \nLarge<\/td>\n 25+ extensions, 150K+ LoC<\/td>\n 15-25 developer-weeks<\/td>\n 14-22 weeks<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nThese estimates cover code migration, testing, and stabilization. They assume developers familiar with both SAP Commerce and modern Java\/Spring. If your team needs to learn Spring 6 and Java 21 concepts during the migration, add 30-50% for the learning curve.<\/p>\n
Critical path items<\/strong> that often determine timeline:<\/p>\n\n- Third-party dependency compatibility (can be a blocker if a critical library lacks a compatible version)<\/li>\n
- Spring Security reconfiguration (always takes longer than expected)<\/li>\n
- Integration testing in CCv2 environments (environment availability and deployment cycle times are bottlenecks)<\/li>\n<\/ol>\n
[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Common Pitfalls” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
Pitfall 1: Bulk find-and-replace without verification.<\/strong> Replacing javax<\/code> with jakarta<\/code> globally will break JDK classes. Always use targeted replacements for specific Jakarta EE packages only.<\/p>\nPitfall 2: Ignoring transitive dependencies.<\/strong> Your code compiles, but a library pulls in an old javax.servlet-api<\/code> JAR that conflicts at runtime. Use dependency analysis tools (gradle dependencies<\/code> or mvn dependency:tree<\/code>) to find and exclude conflicting transitives.<\/p>\nPitfall 3: Skipping the Spring Security migration.<\/strong> “We’ll do it later.” Spring Security changes are deeply integrated with the platform’s authentication and authorization. Postponing this creates a ticking time bomb.<\/p>\nPitfall 4: Not testing with production-like data.<\/strong> The migration may work perfectly with a test dataset and fail with production data volumes. Particularly relevant for JPA\/Hibernate changes where query behavior can differ subtly.<\/p>\nPitfall 5: Underestimating SAP-specific customization points.<\/strong> SAP Commerce has its own patterns for filters, interceptors, and event handlers that layer on top of Spring. These need individual attention – they do not automatically migrate with generic Spring migration recipes.<\/p>\n[\/et_pb_text][et_pb_divider _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_divider][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_heading title=”Closing Notes” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][\/et_pb_heading][et_pb_text quote_border_color=”#457b9d” _builder_version=”4.27.5″ _module_preset=”2c55a9c4-feed-423b-9edb-ae0b5b365cac” text_font=”IBM Plex Sans|IBM Plex Sans_weight|||||||” link_font=”|IBM Plex Sans_weight|||||||” link_text_color=”#1d3557″ quote_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_2_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_3_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_4_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_5_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” header_6_font=”IBM Plex Sans Condensed|IBM Plex Sans Condensed_weight|||||||” locked=”off” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
The Spring 6 and Java 21 migration for SAP Commerce is substantial but manageable. It is primarily a mechanical exercise (namespace changes, API updates) combined with targeted architectural work (Spring Security, build configuration). The code changes are well-understood, and the ecosystem provides good tooling for most of the heavy lifting.<\/p>\n
The key is to approach it methodically: dependencies first, then namespace migration, then Spring-specific changes, then thorough testing at every layer. Resist the temptation to combine this migration with feature work or other architectural changes. Do one thing at a time, and do it well.<\/p>\n