Regarding a comment in the doc about configuration and moving MP config into Jakarta, the easiest thing to do given the current state of Jakarta Config, which essentially boils down to:
public interface Config {
/**
* Loads an object of the supplied {@code type} from the current {@link Config} <em>configuration path</em>.
*
* @param <T> the type of object to load
* @param type the type of object to load; must not be {@code null}
* @return the loaded object; never {@code null}
* @exception NoSuchElementException if the requested object is not found.
* @exception IllegalArgumentException if the supplied {@code type} was invalid for any reason
* @exception NullPointerException if the supplied {@code type} was {@code null}
*/
<T> T load(Class<T> type);
}
and some annotation for customizing the binding fields on a configuration POJO, Jakarta Config could just be released as is with a very simple POJO configuration object view with the details left to the implementation. Vendors supporting MP config would leverage that for the serialized forms, type conversion, etc. Specs would need to define their configuration POJOs. MP config could be the de facto portable format.