I do not know this word "qq".

This is a good question.  Logging utilities are much more flexible.  stderr is
just one channel, and not an especially good one for things like Web servers.
 Everyone writes to the same channel, and the logging overhead to stderr is
incurred with every call; that can have an adverse impact on performance.
Furthermore, it is inflexible: you have to invent your own formats,
disentangle all the output from multiple sources, disentangle important output
from less so, and you can't selectively suppress some log output and not other.

With a library such as log4j, you have very good control.  You can suppress
logging output "below" a certain level of granularity for most stuff most of
the time; that means you might log only "SEVERE" or "ERROR" level messages in
production.  All less critical messages ("WARNING", "DEBUG", etc.) not only
are not emitted, they have negligible impact on production performance.  Only
messages that are emitted cause overhead.

Furthermore, you can have different parts of the system log at different
levels.  For example, if one web service class is troublesome, you crank up
its logging level to DEBUG but leave everyone else ERROR only.

Not only that, you can log each program, each class, even each method to
separate outputs should you choose.  You can even simultaneously log to
multiple outputs, such as the stdout stream and a named log file.  You can
even log to a database.  But wait, there's more.  Logging is configurable at
deployment time via an external resource file, so you don't even have to
hard-code all that control.  This includes formatting and built-in handling of
multiple threads.

Logging is as superior to System.err output (or, shudder, System.out) as a
Ferrari is to a VW.

Congratulations.

BTW, how close to infinite do you have to get to be "almost" there?