Liferay DXP 2023.Q4 Breaking Changes

Breaking changes break or significantly alter existing functionality or code structure. Here are all of the breaking changes for Liferay DXP 2023.Q4. As the product changes and improves, we try our best to minimize these disruptions, but sometimes they are unavoidable.

Changes in Module Source Code

PrefsPropsImpl.java portal-impl/src/com/liferay/portal/util/PrefsPropsImpl.java

• Date: Aug. 31, 2023
• Ticket: LPS-195009
• What Changed: The PrefsPropsUtil.getString(PortletPreferences, String, *) overloads no longer fall back to portal.properties when the portlet preference is not set. Previously, these methods called getString(PortletPreferences, String) first, which uses PropsUtil.get(name) (i.e., the portal.properties value) as its own fallback. Only if that returned null did the methods return the caller-supplied default. Now these overloads call preferences.getValue(name, ...) directly — passing the caller-supplied default (converted to a String for the typed overloads) — so the caller-supplied default is used when no portlet preference is stored.
• Reason: The old behavior caused the caller-supplied defaultValue to be silently ignored whenever portal.properties contained a matching key. This fix ensures the default parameter behaves as documented.

Who Is Affected: Custom code that calls any of the following PrefsPropsUtil overloads and relies on portal.properties providing the value when no portlet preference is stored:

• getString(PortletPreferences, String, boolean)
• getString(PortletPreferences, String, double)
• getString(PortletPreferences, String, int)
• getString(PortletPreferences, String, long)
• getString(PortletPreferences, String, short)
• getString(PortletPreferences, String, String)

How to Adapt: If your code needs portal.properties as the fallback, call PrefsPropsUtil.getString(PortletPreferences, String) (the no-default overload) instead, which still reads portal.properties as its fallback via PropsUtil.get(name). Use the result as you see fit. If your code already supplies a meaningful default and you want that used when no preference is stored, no change is needed — the new behavior honors it correctly.