Alex Boyko

Here is where most of the time spent according to VisualVM: 

I suspect that you attempt to re-use the parser for different java source sets of the project hence the time is lower...

@odrotbohm I recall you were initially asking for metadata re-generation once new java files are added... The problem with this was that class files are not generated at the same...

The newly generated metadata is always checked against the cached one before issuing re-validation, thus, I'd say, this is the least of our concerns for now. The primary concern is...

Lets try this fix for Modulith metadata regen on the tools side: 263930d7b5115aa9cc42cd31110ebdf8a3e86c7f It has some logic to optimize regen on .class file create/change

Preference setting to tun on/off automatic Modulith metadata refresh: 8349671a3ae7d04c6b90b8e201c5164def4e9b84 Lets close this for this release and see how it works out for @odrotbohm

Perhaps completing the CU future exceptionally and then if it has completed exceptionally chain something to the future to invalidate the cache entry... ```java private synchronized CompletableFuture requestCU(IJavaProject project, URI...

Here is the branch with a candidate fix: https://github.com/spring-projects/sts4/tree/cu-cache-fix I have tried artificial exception with combination of time consuming parsing with `THROTTLE` and `DEBOUNCE` reconcile strategy. Seemed to work so...

Lets try the fix: 4ce4f02bf471cd20f89209a765e3cbdd88d6dffd - seems harmless and likely to help with the issue above

I sort of doubt that "send classpath notification" in the IDE has anything to do with the app failing to start... The classpath data is not sent from Eclipse to...