Skip to content

Deprecations and removals in CAP Java 5 #2479

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
StefanHenke wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Deprecations and removals in CAP Java 5 #2479

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
19bbe12
Update migration.md with property and API changes
StefanHenke Mar 31, 2026
d153885
Merge branch 'main' into deprecations-removal-cap-5
StefanHenke Apr 8, 2026
af94683
Removed deprecated methods in UCL AssignEventContext (#2496)
StefanHenke Apr 8, 2026
2cd1433
CAP Java 5.0: Document ServiceExceptionUtils removals in migration gu…
rjayasinghe Apr 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions java/migration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,9 @@ Here, the *migration* `com.sap.cds.services.migrations.MigrateStatements` from C
|Name |Description|Available since|
|--------|-----------|---------------|
|[com.sap.cds.services.migrations.MigrateStatements](../releases/2025/aug25#typed-query-results)|Migrates CQN statements to comply with typed Query API changes in 4.3.0.|4.3.0|
|[com.sap.cds.services.migrations.ServiceExceptionUtils](#removed-java-apis-4-to-5)|Replaces deprecated methods in `ServiceExceptionUtils`.|5.0.0|
|[com.sap.cds.services.migrations.MigrateSaasRegistryDependency](#removed-java-apis-4-to-5)|Replaces deprecated `SaasRegistryDependency` methods `setAppId`/`setAppName`/`getAppId`/`getAppName` with their `xsappname`-based replacements.|5.0.0|
|[com.sap.cds.services.recipes.UclMigration](#removed-java-apis-4-to-5)|Migrates deprecated UCL result getter and setter methods to the new API.|5.0.0|

## CAP Java 4.9 to CAP Java 5.0 (TBA) { #four-to-five }

Expand All @@ -66,6 +69,45 @@ CAP Java 5.0 increased some minimum required versions:
| Spring Boot | 4.0 |
| XSUAA (BTP Security Library) | 4.0.0 |

### Adjusted Property Defaults

Some property defaults have been adjusted:

| Property | Old Value | New Value | Explanation |
| --- | --- | --- | --- |
| `abc` | false | true | Any description. |

### Deprecated Properties

The following properties have been deprecated and might be removed in a future major version:

- `abd`

The functionality provided by these properties is enabled by default and there is no reason to switch these off.
Copy link
Copy Markdown
Contributor

@renejeglinsky renejeglinsky Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence sounds as if we ask the user to not switch off a deprecated property, or? Isn't the exact opposite the case?

Copy link
Copy Markdown
Contributor Author

@StefanHenke StefanHenke Apr 14, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renejeglinsky : I basically copied this sentence over from the previous migration guide. The meaning behind is: Typically, these deprecated properties can be used to toggle a newly introduced or incompatible feature. After some time, we enable these features by default and deprecate the corresponding property. This still gives applications in worst case (safety net) the possibility to switch off the features in the current release. This might give some time for adapting to the new behavior. However, once the property is deleted in the next major, it cannot be switched off anymore and applications have to live with the new feature behavior. That´s why the properties should not be switched off. Maybe only after our explicit recommendation for concrete stakeholders.

Copy link
Copy Markdown
Contributor

@renejeglinsky renejeglinsky Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, is there Is a significant difference between switching it off and not using it. Switching off would mean to not use the new default whereas not using it (that is, delete the property, right?) would mean using the default.
I haven't considered to use it to switch off default behavior.

Suggested change
The functionality provided by these properties is enabled by default and there is no reason to switch these off.
The functionality provided by these properties is enabled by default. If you enabled and tested it already and want to use the default, you can safely remove the property. If you want to stay with the previous behavior und start testing the new default now, you can set it to `false`.

Copy link
Copy Markdown
Contributor Author

@StefanHenke StefanHenke Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see https://github.com/capire/docs/pull/2479/changes#r3084352819

Copy link
Copy Markdown
Contributor Author

@StefanHenke StefanHenke Apr 15, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renejeglinsky: With new default (activated), stakeholders will automatically test the new behavior. Only if they face issues, they might get back to the previous behavior by setting it to false which we, however, strongly discourage. That´s why I wouldn´t mention this here.

What about:

Suggested change
The functionality provided by these properties is enabled by default and there is no reason to switch these off.
The functionality provided by these properties is enabled by default. This reflects its intended behavior once the properties are deleted in future releases.


### Removed Properties

The following table gives an overview about the removed properties:

| Removed Property | Replacement / Explanation |
| --- | --- |
| `abc` | Any description about replacement |

### Removed Java APIs { #removed-java-apis-4-to-5 }

- Removed deprecated methods:
- `com.sap.cds.services.ServiceExceptionUtils.getLocalizedMessage(String code, Object[] args, Locale locale)` → `getLocalizedMessage(code, args, locale, true)` (pass `true` for `errorStatusFallback` to keep the previous behavior)
- `com.sap.cds.services.ServiceExceptionUtils.getMessageTarget(String target)` → `MessageTarget.create(target)`
- `com.sap.cds.services.ServiceExceptionUtils.getMessageTarget(String parameter, Function<StructuredType<?>, Object> path)` → `MessageTarget.create(parameter, path)`
- `com.sap.cds.services.ServiceExceptionUtils.getMessageTarget(String parameter, Class<E> type, Function<E, Object> path)` → `MessageTarget.create(parameter, type, path)`
- `com.sap.cds.services.ServiceExceptionUtils.getMessageTarget(Path path, CdsElement element)` → `MessageTarget.create(path, element)`
- `com.sap.cds.services.mt.SaaSRegistryDependency.getAppId()` → `getXsappname()`
- `com.sap.cds.services.mt.SaaSRegistryDependency.setAppId(String appId)` → `setXsappname(appId)`
- `com.sap.cds.services.mt.SaaSRegistryDependency.getAppName()` → `getXsappname()`
- `com.sap.cds.services.mt.SaaSRegistryDependency.setAppName(String appName)` → `setXsappname(appName)`
- `com.sap.cds.feature.ucl.services.AssignEventContext.setUclResult(SpiiResult)`, use `setResult(SpiiResult)` instead.
- `com.sap.cds.feature.ucl.services.AssignEventContext.getUclResult()`, use `getResult()` instead.

## CAP Java 3.10 to CAP Java 4.0 { #three-to-four }

### New License
Expand Down
Loading