Clarify what impact Jakarta EL 4.0 has in 7.19 to 7.20 migration guide

[mboskamp]

Acceptance Criteria (Required on creation)

The 7.19 to 7.20 migration guide has a section about Jakarta EL 4.0 and the impact that switching from JUEL to Jakarta EL has.

Bean method invocation changes with regards to method parameters. All values, including null values, are converted as described in the EL API specification. As a result, null values will be coerced into the type defined by the method. For example, calling myBean.setStringAttribute(null), requiring a String parameter, now leads to null being coerced into an empty String "". Previously, the null value was passed on as is.

It is not 100% clear what impact this can have. We should add a real-world example using execution context variable.

Given the following Java snippet. When used in an expression (e.g., in a service task), the result may be different from that of previous Camunda versions. Jakarta EL will treat nullableVariable as empty string when it is null. This will result in the engine looking for a task with id of "" (empty string) whereas normally it would ignore the taskId parameter. This is an example of how the new behavior can break custom implementations when using expressions. Calling the same API with regular Java code (e.g., from an external task or Java delegate) will not produce a different behavior compared to previous Camunda versions. The Camunda API did not change.

execution.getProcessEngineServices().getHistoryService().createHistoricTaskInstanceQuery().taskId(nullableVariable).list();

Hints

Links

• https://github.com/camunda/camunda-docs-manual/blob/7.21/content/update/minor/719-to-720/_index.md
• https://jira.camunda.com/browse/SUPPORT-23863

Breakdown

### Pull Requests

Dev2QA handover

• [ ] Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment