Unable to use Dependency Injection in Service class when having final method

[Pavlin619]

Currently, we are trying to integrate Spring Boot Chaos Monkey library into our project. During the process, we wanted to create an experiment, which includes delayed response from one of our services.

The service under test is an abstract class annotated with @service and @requiredargsconstructor and has a few classes, which are injected into it. To be more precise, we are testing a concrete implementation of the abstract class, but the method that we are testing is public final in the abstract class, therefore i am describing the abstract class.

When we add the dependency to Chaos Monkey library and we use spring.profiles.active: chaos-monkey, each dependency in the abstract class appear to be null. Therefore, it throws NPE, when we invoke the request. This happens only when we activate the chaos-monkey profile and is not the current production behaviour.

After digging down into the possible root cause for 2 days, I found out that the problem is actually caused by the final keyword in the method in the abstract class. When, I remove it works as expected, but it is pretty strange side effect. Moreover, changing the production code for the sake of integrating the library is not the desired approach, so i would be glad if you can assist with solving this issue and finding the root cause for it.

Expected Behavior

When i activate the Spring Boot Chaos Monkey library, I do not expect to touch any of my production code and if i have not configured any assaults I want it to act as if there is not dependency to this library. In other words, I do not want to remove the final keyword from my code :)

Current Behavior

Spring is not able to inject any dependency to the service that has final method and all of them appear to be null.

Possible Solution

Removing final keyword from the method signature solves the issue for some reason.

Steps to Reproduce

In my case, i am producing the issue with having an abstract class with public final method, which uses injected class in its logic. Apparently, all the injected classes in the class appear to be null (Spring is not able to inject them), so this could also be seen from debug console.
The issue is reproduced with the latest version 3.2.2. I also reproduced it with 3.1.0, 3.0.2, 3.1.2.
Our Spring Boot application is using Spring Boot 3.4.5.

Context (Environment)

This issue becomes a deal breaker for integrating the library, because we are afraid of these side effects to our production code and we do not want test library integration to affect the behaviour of our newly developed features.

[Pavlin619]

After diving deeper into the currently mentioned issues, I saw this one: #287. It explains the same issue as the one mentioned above. Judging on the output of the discussion there is an enhancement of the library, which allows us to exclude certain components from being proxied.

I know it is a limitation that comes with Spring AOP, but i just wanted to make sure if this the current approach that we should follow when we have such final classes and methods. Currently, I am using chaos.monkey.watcher.exclude-classes configuration in order to list each class, which is final or contains final methods. This approach currently works, but is a very bad side effect IMO. Imagine integrating the library in a big service, where you already have thousands of lines of code. Should i go through the whole project and search for each class or methods that has final modifier so that i could explicitly include this class in the exclude-classes list?

Is there a more elegant way to handle this issue without touching the production code and also without having any side effects on its behaviour such as the one that i mentioned in the above issue?

[kunaagar]

Hello!
I've investigated the issue where Chaos Monkey fails to inject dependencies when final methods are present in abstract service classes. After thorough analysis, I'd like to share my findings and suggest a design approach that resolves this naturally—not as a workaround, but as a positive architectural recommendation.

This is my first contribution to the community, and I'm sharing it in the spirit of collaborative problem-solving. I'd appreciate your feedback and discussion on this perspective.

Problem

When integrating Chaos Monkey with services containing final methods in abstract classes, the following occurs when the chaos-monkey profile is activated:
java.lang.NullPointerException: Cannot invoke method because dependency is null
This happens despite the same code working perfectly without the Chaos Monkey profile

Root Cause Analysis

Spring AOP offers two proxying mechanisms:

• JDK Dynamic Proxies - Create proxies by implementing interfaces (no subclassing required)
• CGLIB Proxies - Create proxies by subclassing the target class

Why Final Methods Cause Issues
When CGLIB attempts to proxy a class hierarchy with final methods, the following chain of events occurs:

ConcreteService (CGLIB tries to subclass this)
↓ extends
AbstractService (contains final method)
↓ final method cannot be overridden in Java
Proxy subclass creation partially succeeds
↓ but disrupts dependency injection lifecycle
Result: Dependencies remain null
↓
NPE when final method is invoked

My Understanding is :

• CGLIB creates a subclass proxy to wrap the original bean

• When this proxy has a final method it cannot override, Spring's bean instantiation and injection lifecycle gets disrupted

• The proxy is created, but the original bean's dependencies aren't properly injected into the proxy instance

Interface-Oriented Architecture

Rather than viewing this as a limitation to work around, I'd like to suggest this is actually an opportunity to adopt a more robust design pattern that's beneficial beyond just Chaos Monkey.

Key Principle: Spring's ecosystem is optimized for interface-oriented architecture, not class-based hierarchies with final methods. This isn't a Chaos Monkey quirk—it's a fundamental design principle that applies to all proxy-based AOP frameworks.

Recommended Pattern: Interface-First Design

• Define a clear contract via interface

public interface IServiceContract { String execute(); }

• Update abstract class to implement the interface
  `@Service
  @requiredargsconstructor
  public abstract class AbstractService implements ServiceContract {
  public final SomeDependency dependency;
  public final AnotherDependency anotherDependency;

  @OverRide
  public final String execute() {
  return dependency.getMessage();
  }
  }`

• Inject via interface
  Instead of using public final AbstractService service inject service using interface `public final IServiceContract service``

• Configure application to use JDK dynamic proxies
  spring.aop.proxy-target-class: false # Use JDK dynamic proxies (interface-based)

Broader Framework Compatibility

Works seamlessly with all proxy-based AOP frameworks:

• Chaos Monkey (fault injection)
• @transactional (transaction management)
• @Cacheable (caching)
• @async (asynchronous execution)
• Spring Security (interceptors)
• Custom aspects

Future-Proof Architecture

When migrating to different frameworks or proxy mechanisms, interface-based design continues to work reliably without modification.

Understanding the Trade-offs: When and How to Use Final

I want to acknowledge that final methods serve a legitimate purpose in design.
Here's my honest perspective:

Use Interface-First Design When:

• You use or plan to use Chaos Monkey or proxy-based AOP
• Building microservices or layered applications
• You value loose coupling and testability
• You want maximum framework compatibility
• Team members use multiple AOP frameworks

You Can Use Final Methods When:

• Your service doesn't use any AOP frameworks (and won't in the future)
• You intentionally want to prevent method overriding for security/design reasons

Honestly, this isn't about never use final—it's about choosing the right tool for the job. Interface-based design is the right tool for services in modern Spring Boot applications that leverage proxy-based AOP.

Looking into this made me appreciate Spring's design more. Its interface-focused setup solves many problems—working well with Chaos Monkey, and being easy to test, maintain, and stay flexible.

Following the framework's limits helps make better, lasting design choices.

Thanks for keeping Chaos Monkey updated. It's a great tool for building system resilience, and this issue clarified its workings and benefits.

I look forward to the community's thoughts and an insightful discussion!