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.
_______________________________________________
dev mailing list
[email protected]
http://www.slf4j.org/mailman/listinfo/dev
