通过 CDI 注入记录器，一种反模式？

Question

Looking at this code:

@Stateless
public class AStatelessEJB {

@Inject
private Logger logger;

(...)

Why a logger, which is typically final and static, is injected by CDI into a stateless EJB (as an instance variable)?

Is there any advantage? Or only disadvantages such as:

• overhead of CDI lookup (per each bean initialization)
• overhead of CDI initialization (per each bean initialization)
• overhead of CDI injection (per each bean initialization)
• overhead of garbage collector clean up (each time the bean gets destroyed)

Answer 1

if you evaluates it from a performance perspective view... there is no big differences but static initialization usually is better than a managed bean.

Usually, CDI will require a little more processing at application initialization and at contextual instance creation time. It will require a few more lines inside a producer method/class but will provide easy of use and certain kind of flexibility. Btw with CDI you can manage one instance per class or application with a minimal producer method.

Advantages:

• Easy to provide abstraction from common logging frameworks
• Easy to add support for additional features like internationalization and localization
• Easy of use (simple like use an annotation)
• Easy of manage multiple implementations/configurations (simple like use multiple qualifiers)
• Standardize use (like other fields)

Disadvantages:

• Additional minimal processing cost
• Other tools like Lombok provides easy of use and provides annotation configuration too (at compile time and in a static way).
• Usually is not required additional features for logs (like internationalization/localization).

In my opinion and summarized, I prefers to use an static field but it is not a bad practice use a cdi bean if you want certain point of abstraction, provide additional features, provide multiple Logger implementations/configurations or provide something ease of use to developers.

Answer 2

I think Ariel's answer is correct. I wanted to add that you may have a fundamental misunderstanding of how CDI works: CDI does not inject the beans directly, nor does it instantiate the beans for every injection point. CDI Injects proxies, which have a reference to the real bean. These proxies are dirt cheap to create and gc. SL4J is also pooled and optimized for quick logger lookup. Combine these two, there are likely far more previous items that would affect your application that a very lightweight CDI injection.

When doing any performance testing, the number one rule is to use a profiler. I think getting yourself a good test setup where you can evaluate your assumptions would be key. That being said, I think CDI Injections will likely be as-fast or faster.