There is a very small feature that could be added to Java in order to improve it significantly: Add names to the Parameter object in the Reflection API.

When creating a new Object in Java,  the parameter list for the constructor or factory provides the contract.  Unfortunately,  a key element of this contract is missing at run rime when it is needed most.  If a constructor takes multiple values of the same type,  the only way to distinguish between them are the names of the parameters.  For example,  the JDBC API to create a new connection takes three parameters: the username and password to use for the connection authentication and authorization, and the URL of the Datasource.  However, all three values are strings. In order to distinguish between them,  the user needs to know the order of the parameters:  is it URL first or UserID first?  

Building a new object from a persisted dictionary is common enough that there is a different API as well that takes a Properties object.  This variation loses all documentation about what is required to authenticate a connection: username and password.  Since the format of the URL is also Driver specific,  the user is thus relegated to digging through the documentation to figure out how to correctly create a Connection.  However, reading the documentation is not an option for an automated tool.

What Java lacks is a standardized and automated way to map a key-value pair collection to a function.  The mechanism should look like this.

private static Object createInstanceFromProperties(Method method, Properties properties)
throws InstantiationException, IllegalAccessException, 
       InvocationTargetException, NoSuchMethodException {
    //This is the new call.
    String[] paramNames = method.getParameterNames();
    //Spacing is due to limitation of web display for angle bracketed expressions.
    Class < ? > [] argsTypes = method.getParameterTypes();
    

    Object arguments[] = new Object[argsTypes.length];
    for (int i = 0; i < paramNames.length; i += 1) {
        String val = properties.getProperty(paramNames[i]);
        if (argsTypes[i] == java.lang.String.class) {
	    arguments[i] = val;
        }else{
            arguments[i] = argsTypes[i].getConstructor(java.lang.String.class).newInstance(val);	
	}
    }
    return method.invoke(null, arguments);
}

A simple variation can work with a Constructor object instead of a Method object. One assumption from the above code that should be explicit is that the framework using this call has enough information to determine which variation of the Method or Constructor to find.

I wouldn't ordinarily implement an API like this as Parallel arrays, but in this case, it is the least impact on the existing API. There is no "Parameter" object in the existing API.

Since existing compiled classes would not have provided the array of names, one version of Java should be provided as a transitory step which will allow the JDK to return a Null if the class does not provide the appropriate strings.