spring-graalvm-native | Spring Native for GraalVM | Application Framework library

I think you are right about the problem. If you were doing build time weaving, it would be totally fine as the modified byte code will be fed into GraalVM native-image for analysis and inclusion in the image. If doing loadtime weaving I believe it can work but haven't confirmed recently if you use loadtime weaving at the point the native-image is being built (via setting the java options to include the aspectjweaver agent), the classes will be woven as they are loaded and the woven form will be included in the image. It can never really work at image runtime because there is no notion of classes any more, and classes cannot be dynamically defined.

So yes, since Spring AOP can be done quite late on, as configuration is resolved, there may be problems. Take a look at the spring native project for the very latest support building your Spring projects into native-images, but we have no samples there for Spring AOP right now as I recall. I'd encourage you to raise issues against that project, including a sample project that show your specific problem can be invaluable. You haven't mentioned how you are creating the native-image right now which may influence my recommendations. I think pushing some analysis/weaving a bit earlier in the process could make it work but haven't been into that space yet.