My idea is using enum as log message definition. enum value is log message id and log message is annotation value associated with enum.

-------------- sample code

-------------- public interface Logger {

public enum LogMessages { @Message("wrong password") // log message is annotation value. WRONG_PASSWORD // enum value is log id. }

public static class Test {

public void test() { Logger logger = new Logger() {

public void warn(Enum<?> message) { // No-op, this is a mock }

}; logger.warn(LogMessages.WRONG_PASSWORD); } }

public void warn(Enum<?> logid); }

---

I think there is advantage using enum definition discussed below.

enum has information of package and definition class and field. Using this feature , I've designed 3 feature.

1. log message definition using enum For example sample code, it can define enum with log message. so developer don't need to write property file. property file must ensure consistency to log id by hand. enum and annotation do by compiler.

2. default property file Because enum has class definition, log api is referable declared class of enum. Log api can load propery file from using declared class name. for example if enum class name is "example.LogMessages", default propery file is "example/LogMessages.properties".

3. package EnumMap must create per　enum class. so if log id is enum, they aren't duplication.