Generating classes from enum
I understand your concerns here. This is a messy situation, and Java (like most languages, I believe), makes it relatively hard to build up interdependencies during the bootstrapping of the classes, classloaders, etc.

What would be ideal is if you could have an Enum that allowed the following:

MessageProcessor processor = message.getMessageType().getProcessor();


but, that would require the MessageType to be constructed knowing what it's processor is.... but you need to map that on a case-by-case basis, based on the factory that supplies them.

What is certainly not ideal, is having public static methods that create new Maps each time they are called....


public static Map&lt;MessageType, MessageProcessor&gt; getProcessors() { ...



Why does it need to be public... what happens if it is called multiple times?

That's an ugly solution.

The ideal solution would be to construct the MessageProcessor at the same time as the MessageType, but, since that can't be done (as the MessageType is a parameter to the factory), I would instead recommend that you create a synchronized, or locked, or atomic method that is part of the Enum, and handles the situation for you. If your factory has the method:

public MessageProcessor getMessageProcessorFor(MessageType mType) {
    .....
}


then your enum could have a private setup like;

enum MessageType {
    TYPE1, TYPE2, ... , TYPE999;

    private final AtomicReference&lt;MessageProcessor&gt; processor = new AtomicReference&lt;&gt;();

    public MessageProcessor getProcessor() {
        MessageProcessor proc = processor.get();
        if (proc != null) { 
            return proc;
        }
        proc = FactoryClass.getmessageProcessorFor(this);
        if (processor.compareAndSet(null, proc)) {
            return proc;
        }
        // there was a race condition, we lost, so use the winner
        return processor.get();
    }
}


This is a compromize I use quite often. It gives you an abstraction between the class-load initialization, and the runtime usage of the enum. 

It has the following benefits:


you have a simpler run-time execution model.
your exceptions, if any, related to creating the MessageProcessor have better traces.
you do not have complicated circular dependencies at construct time.
you only create instances for types you use.


on the down-side, you have the following:


slight performance hit each time you call the method as it checks its state.
well, no 2, really.