[slf4j-dev] slf4j i8ln

[Takeshi Kondo]

> If I followed you, the idea is to encode the resource bundle *keys*  
> within
> enums. You still need to check the consistency of the resource  
> bundle keys,
> including copies found in various language variations so that they  
> match the
> enums. I can see how this would be useful if the IDE somehow knew  
> about the the
> resource bundle keys and the enums and cross checked things. Without  
> tooling
> support, one would still need to manually match the enum keys with  
> those found
> in resource bundle. I still don't see the gain with enums. What am I  
> missing?

You don't understand my idea a little.
My idea is to use enums as log message id.
The resource bundle keys is one of ways binding enums to log messages.
Of cause, we need to check the consistency of the resource bundle keys.

> public class enum LogMessages{
>  @Debug("debug log message")
>  TEST0001
> }

Log level annotation is one of ways.
This is type safe.

If we follow up type safe, there is my thinking idea.
----
Binding enums to log messages by coding
----
public class JapanLogMessages  implements LocalizedMessage<LogMessages>{
   // return target locale
   public Locale locale() {
      return Locale.JAPAN; // target local
   }
   // return message bound log message id.
   public String toMessage(LogMessages logId){
      switch (logId){
      case TEST0001:				   // log message id
         return "japanene log message"; // return localized message
      }
      return null;
   }
}
----
Switch case is type safe.
In development, enums is useful because it is type safe.

I think enums have application possibility.