This is an issue when a method designated for automatic invocation at application startup is declared as a class-level method rather than an instance method, is configured to produce managed objects, or requires input arguments. Such methods will not be properly invoked during application startup.

In Java, this specifically refers to methods annotated with @Startup.

Why is this an issue?

Annotations or attributes that mark methods for execution during application startup in dependency injection frameworks have specific requirements for how these initialization methods must be declared.

When you mark a method for startup execution, the dependency injection framework generates initialization hooks that trigger the method when the application starts. For this mechanism to work correctly, the method must meet three requirements:

• Non-static: The method must be an instance method. Dependency injection frameworks work by creating managed component instances and invoking methods on those instances. A static method belongs to the class itself, not to an instance, so the framework cannot properly manage its lifecycle or invoke it as part of component initialization.
• Non-producer: The method cannot be a producer method (one that creates and provides instances for other components to consume). Producer methods are designed to create and provide component instances, not to perform initialization logic. Combining startup execution markers with producer functionality creates a conflict in the intended purpose of the method.
• No arguments: The method must not accept any parameters. The framework invokes these methods automatically at startup and has no mechanism to provide argument values. If a method requires parameters, the framework cannot call it.

What is the potential impact?

When methods designated for startup execution don’t follow the required signature, the initialization logic will not execute at application startup. This can lead to:

• Missing configuration or setup steps that are essential for the application to function correctly
• Uninitialized resources or connections that other parts of the application depend on
• Runtime errors when the application tries to use components that were supposed to be initialized at startup
• Silent failures where the method is simply not called, making the problem difficult to diagnose

How to fix it

Remove the static modifier from the method to make it an instance method. Ensure the method has no parameters and is not annotated with @Produces.

Code examples

Noncompliant code example

@ApplicationScoped
public class EagerAppBean {
    @Startup
    static void init() {  // Noncompliant: static method
        doSomeCoolInit();
    }
}

Compliant solution

@ApplicationScoped
public class EagerAppBean {
    @Startup
    void init() {  // Compliant: non-static, no arguments
        doSomeCoolInit();
    }
}

Resources

Documentation

• Quarkus - Application Initialization and Termination - Official Quarkus guide on using @Startup and other lifecycle annotations
• Jakarta CDI Specification - The specification for Contexts and Dependency Injection in Jakarta EE