perf: skip generated directories when resolving Java classes

[Deleted user (ghost)]

Summary

Skip common generated/build directories while discovering Java classes to avoid expensive filesystem traversal during auto-detection.

Why

Large projects often contain generated sources under folders such as build, out, target, and generated. Recursive scans were walking these directories even when they were not relevant, which slowed launch resolution and could trigger unnecessary package detection work.

Changes

• Skip generated, build, and IDE metadata directories during Java class lookup
• Add a regression test covering source-vs-generated class detection

Validation

• npm test -- --grep "ignores generated build directories"

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[wenyt (wenytang-ms)]

The performance goal makes sense, but a shared directory-name blacklist is too broad. Names such as classes, out, and generated can be legitimate Java package directories, and generated sources may also belong to the project's source roots. Applying the same exclusions to compiled-class detection can break both main-class and classpath resolution.

I'd suggest separating source discovery from compiled-class lookup and pruning only directories known to be irrelevant to each search, rather than matching names at every depth. Where available, we could reuse the existing Java language-server resolvers, while retaining a bounded filesystem fallback for standalone projects.

Since source discovery already skips build and target, it would also help to identify the specific traversal causing the slowdown and target the optimization there.