No it's not; the SLF4J Logger interface has no inherent concept of a level. It has "isXEnabled" methods, but there's nothing to stop you writing an implementation that returns true (or false) for all of those. You could even write an implementation that returns a logger with those methods randomly returning true or false each time you called it if you wanted to - SLF4J doesn't care.
Agreed, the official interface associates no explicit level semantics. (In fact a logger that retrieves just a random 1% sample of all log messages might do exactly that.) Not that it changes anything about the point I'm making - since SLF4J does not make assumptions about inter-level dependencies, bindings and bridges are free to do whatever pleases them, including establishing a level relationship.
The fact that there happen to be different loggers for different names with different persistent configured levels in Logback is an implementation detail specific to Logback.
Routines that call LoggerFactory and Logger see * that there's a namespace that maps names to Loggers (ILoggerFactory#getLogger), and * that each Logger has a level (in the form of isXEnabled). Nothing of that is specific to Logback. (In fact it cannot be specific to Logback. It's the interface that SLF4J exposes to client code that may emit messages, and the whole point of SLF4J is abstracting away the specifics of logback or any other backend.)
It's going to be a lot, lot easier if we refer to Logback loggers configured for Logback, so if you don't mind I'll quote you as if you had:
So for each logger that's configured for Logback, I want to create a JUL logger with the same logging level as its Logback counterpart. This should drastically cut down on the number of log messages created and thrown away.
SLF4J can use other backends than logback, and the JUL bridge should work in these cases, too. So I have to strongly disagree: using logback specifics for the JUL bridge would defeat the whole purpose of SLF4J. One thing where I was overly specific was when I was referring to logback.xml. With a different backend, the configuration file would have a different name. So, it's really the configuration as far as it's exposed at the SLF4J level that needs to be reflected down to JUL. Regards, Jo