Incorrect @PreDestroy order, should be the reverse of the @PostConstructor init order

[raisoftware]

Rob note:

This issue has been translated into: "@PreDestory order should be reverse of bean registration/construction order"
... so not related to @PostConstruct order per se.

Note that the "registration/construction order" is typically determined based on constructor dependencies. So we can think of this as ... "based on constructor dependencies, the @PreDestrory order now defaults to the reverse order of that [we can almost consider this a BUG fix]. ".

We then use explicit priority to control the exact @PreDestory order as necessary beyond that.

---

Running the demo app (https://github.com/avaje/avaje-inject-examples/blob/main/modular-coffee-app) with added println() produces the following output:

    ElectricHeater:constructor()
   Thermosiphon:constructor()
   MainWithNo:constructor
   CoffeeMaker:constructor()
   ElectricHeater:init()
   Thermosiphon:init()
   CoffeeMaker:init()
   Aug 07, 2025 1:20:53 PM io.avaje.inject.spi.DBeanScope start
   INFO: Wired beans in 24ms
   CoffeeApp:BeanScope
   ~~~heating core ElectricHeater ~~~
   => => pumping core Thermosiphon => => as
   [_]P Coffee [_]P
   ElectricHeater:close()
   Thermosiphon:close()
   CoffeeMaker:close()

However, using the C++ analogy, the destructors should run in the reverse order of constructors. If ElectricHeater and Thermosiphon were services used by multiple Makers, the Makers should have been flushed and closed before shutting down the Makers, or the Makers could not have finished processing cleanly.

[SentryMan]

You can set the order of predestroy manually

[raisoftware]

Are you suggesting to use the priority attribute of @PreDestroy ? Suppose you would need the same priority attribute for the @PostConstruct, how would that work for you?

[SentryMan]

Ordering is not part of the @PreDestroy/@PostConstruct JSR-250 specification, so you shouldn't be developing with order in mind for lifecycle. The reason we added a priority feature for pre-destroy is to address situations where things like a database bean might be destroyed prematurely.

Suppose you would need the same priority attribute for the @PostConstruct, how would that work for you?

Do you have such a use case? If so, please describe, and then I can make a PR to add such a feature.

[raisoftware]

Ordering is not part of the @PreDestroy/@PostConstruct JSR-250 specification, so you shouldn't be developing with order in mind for lifecycle.

It may not be part of the specification, but without reverse topological ordering the @PreDestroy mechanism is basically unusable for any class which uses its dependencies during the close() process. Because it will attempt to use a closed() service, and will fail.

Do you have such a use case? If so, please describe, and then I can make a PR to add such a feature.

It's a generic problem, but suppose this dependency set:

Logger()
Database()
MessageService(Logger, Database)
OrderService(MessageService)

When OrderService.close() is called, it may want to post a message to MessageService like "orderAborted" before returning.
Similarly MessageService might want to log "closing" to Logger as well as dump all the buffered messages to the Db before closing. If any of those has closed before their client instances, the buffered messages would be lost or the log messages disapperead. Now multiply this by 30 and you will see that a manual solution like priority would be too error prone and what is needed is a reverse topological sort.

FYI, micronaut-inject calls @PreDestroy in the correct order.

[SentryMan]

That's not a post-construct use-case, but it's convincing enough for the pre-destroy. I'll see what I can do.

[rbygrave]

Hi @raisoftware , I've put in a "Rob note" into the description of this ... hopefully to clarify what this issue has ended up as, which is around fixing the default @PreDestroy ordering relative to constructor dependencies [and nothing to do with @PostConstruct per se].

Let me know if you are ok with that or we can adjust that as needed etc.

Can you confirm that we have interpreted this issue correctly and that you are somewhat satisfied with the change?

Cheers, Rob.

[raisoftware]

Hi Rob, @SentryMan
Thank you for looking into this. I can confirm the issue seems solved based on my limited testing.
PS: Your fix was scary fast!