So as I can understand the suggested by the latest FAQ Java 17 transition plan is:
- Now - February 6th, 2024: create a transition plan from Java 8 to Java 17, a list of all connectors (standard and custom) to update.
- February 6th - April 2024: keep an eye on connector updates. Begin upgrading custom connectors using the Mule/Java SDK, XML SDK, and REST Connect with the Connector Upgrade Playbook.
- April 2024: start updating the project SDK to Java 17, test and deploy applications; updating Mule Gateway Policies and Proxies via Anypoint API Manager.
So, here are my questions:
1. Is the transition plan from above right?
2. Is changing the version of the connectors within all applications the only effect of transition?
3. Should we be aware of MuleSoft switching to other libraries within its inner implementations so some of the file formats will be unacceptable anymore or vice versa? For example, due to Dataweave using Poi-OOXML libraries to read OOXML files and Strict Open XML Spreadsheet is not supported by Poi, Dataweave itself does not support it correspondingly (source: https://help.mulesoft.com/s/article/Strict-OOXML-isn-t-currently-supported-please-see-bug-57699).
4. In case any application had Java code within it, should the last be rewritten to be supported with Java 17?
5. What is the recommended date to update all environments and applications within it to Java 17?
Yes the plan is right. Note in Feb , customers can start updating their API instances with Java 17 compatible MuleSoft gateway included policies. For apps that have no custom code , the main action is to update to java 17 compatible connectors , however for apps with custom code one needs to update custom libraries , jars etc and needs to be tested and redeployed. Our recommendation is to manage this upgrade in 2024. Mule 4.6 LTS will be supported from Feb 2024 to Feb 2026 . Not sure about the source of the concern whereby inner library changes required to support Java 17 will lead to limiting support on some features - incase a particular library drops support - it will be detected via our tests and we should be able to understand that upgrade is a problem . The example on dataweave used is of a library that is limited by default, not something that was supported and then taken away. However if there is a particular concern , we would be happy to know.