> I'm concerned we do not understand the others enough to design the interfaces well enough
That's a risk. All I'm suggesting is that, as we alter job submission here we should keep in mind where we'd like to go. In particular, we should try not to change it incompatibly more than once. Currently we support specification by class name. If we add another Java-specific mechanism now, we'll have to support it too going forward. If we know we'll change it again soon, then that will be three mechanisms we'll need to support for a time. Perhaps that's tolerable, but two would be better. This may be an opportunity to "future-proof" job submission, or it may not be.
For example, perhaps your implementation will use the existing mechanism to provide the new capability, e.g., it will set a job's mapper to JavaSerializedMapper, that will then look on the classpath for a particular file that contains the serialized mapper. In this case we can argue that the underlying mechanism isn't changed and all's well. On the other hand, if we were to add new job properties that the framework uses in preference to the existing properties, then we should more carefully think about what these are and whether they're steps in the direction we want job configurations to take. Does that make sense?