Support [package-]private init/destroy methods in AOT mode

[sbrannen]

Overview

Prior to this commit, private (and non-visible package-private) init/destroy methods were not supported in AOT mode. The reason is that such methods are tracked using their fully-qualified method names, and the AOT support for init/destroy methods previously did not take fully-qualified method names into account. In addition, the invocation order of init/destroy methods differed between standard JVM mode and AOT mode.

This commit addresses these issues in the following ways.

• AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(), DisposableBeanAdapter.determineDestroyMethod(), and BeanDefinitionPropertiesCodeGenerator.addInitDestroyHint() now parse fully-qualified method names to locate the correct init/destroy methods.

• AbstractAutowireCapableBeanFactory and DisposableBeanAdapter delegate to a new MethodDescriptor record which encapsulates the parsing of fully qualified method names; however, BeanDefinitionPropertiesCodeGenerator duplicates this logic since it resides in a different package, and we do not currently want to make MethodDescriptor public.

• Init/destroy methods detected via annotations (such as @PostConstruct and @PreDestroy) are now invoked prior to init/destroy methods that are explicitly configured by name or convention. This aligns with the invocation order in standard JVM mode; however, InitializingBean#afterPropertiesSet() and DisposableBean#destroy() are still invoked before annotated init/destroy methods in AOT mode which differs from standard JVM mode.

• Unit and integration tests have been updated to test the revised behavior.

Related Issues

• InitDestroyAnnotationBeanPostProcessor @PostConstruct method may not get called [SPR-5945] #10614
• Private init/destroy method may be invoked twice #28083
• Add support for private init/destroy methods in AOT mode #30654
• Invoke lifecycle methods in AOT mode in the same order as standard JVM mode #30755

[sbrannen]

@jhoeller and @snicoll, if either of you have time, I would appreciate a quick review of this PR.

In any case, I think we should decide if we want to address the following (with a separate GitHub issue).

however, InitializingBean#afterPropertiesSet() and DisposableBean#destroy() are still invoked before annotated init/destroy methods in AOT mode which differs from standard JVM mode.

This difference in behavior stems from the fact that we merge init/destroy method names during AOT processing, and that causes @PostConstruct/@PreDestroy methods to be invoked after InitializingBean#afterPropertiesSet() and DisposableBean#destroy() when running in AOT mode.

[sbrannen]

Fixed in 3181dca

[sbrannen]

Reopening to ensure this has been tested in a native image, regarding reflection hints, etc.

[sbrannen]

Reopening to ensure this has been tested in a native image, regarding reflection hints, etc.

I have confirmed that the fix works within a GraalVM native image by creating the sample application as described in #30654 and modifying the build.gradle script as follows.

ext['spring-framework.version'] = '6.0.11-SNAPSHOT'

repositories {
	mavenCentral()
	maven {
		url "https://repo.spring.io/snapshot"
	}
}

To be thorough, I also verified the recently introduced support for shadowed package-private init/destroy methods (see #30718).

Using the following classes...

// resides in a different package than the other beans
public class SubpackageSuperBean {

	@PostConstruct
	void init() {
		System.out.println("Init SubpackageSuperBean");
	}

	@PreDestroy
	void destroy() {
		System.out.println("Destroy SubpackageSuperBean");
	}

}

public class SuperBean extends SubpackageSuperBean {

	@PostConstruct
	private void init() {
		System.out.println("Init SuperBean");
	}

	@PreDestroy
	private void destroy() {
		System.out.println("Destroy SuperBean");
	}

}

public class DemoBean extends SuperBean {

	@PostConstruct
	private void init() {
		System.out.println("Init DemoBean");
	}

	@PreDestroy
	private void destroy() {
		System.out.println("Destroy DemoBean");
	}

}

... the output from the native executable is:

Init SubpackageSuperBean
Init SuperBean
Init DemoBean

Destroy DemoBean
Destroy SuperBean
Destroy SubpackageSuperBean

In light of that, I am closing this issue.