IssueTracker

As discussed "offline":

(1) accessing .class files via the VFS is already a problem because it pollutes it with unnecessary often changing content

(2) an alternative is to access files directly but the VFS is, at least for now, convenient to deal with .jar files

(3) the proposal we greed on is to return file urls (used in IDEA) from class finders that can be translated to Path in the case of local files and can still be used with the VFS when dealing with .jar files.

There are several areas not strictly related to this issue that still need attention:

1. We need to make sure that the first time build directory is created under a Gradle project during build it appears in the project view when build finishes (without switching to other apps i.e. without triggering the VFS refresh manually)

2. Various class loader implementations involved in compose preview (and other layout related components) use the VFS to load .class files produced by Gradle build. This was done as a simplification/unification which allowed us to handle both .class and .jar files similarly as we rely on the VFS support for paths like jar://<path-to-jar>!/path/to/.class.

   Diego confirmed that this should be possible to separate execution paths and implement .jar handling directly( or at least use the VFS) for .jar files only. As the first step we need to replace our APIs that currently return VirtualFiles with APIs that return VFS urls and resolve them in the caller code. (I believe it can be pure refactoring). Once done the core team should be able to deal with .jar and .class files differently and eventually stop bringing .class files to the VFS storage. As we know it might have a substantial performance impact.

Post ag/Ia1a5ea0c0be0bf29478d99559e4cd06e80ae832d, PSI is built for the R class, which requires using VirtualFile i.e. having up-to-date VFS state. This complicates things a bit, and requires R.jar refresh.

I collected some numbers. Here is how long it takes to collect all compiler output paths (can be cached) and to do a recursive VFS refresh:

- Simple MyApplication
2023-10-02 18:55:53,370 [ 234586]   INFO - STDERR - Collecting outputs took 2[ms] and refresh took 210[ms]

- 1000 subprojects
2023-10-02 19:22:44,012 [1845228]   INFO - STDERR - Collecting outputs took 815[ms] and refresh took 2548[ms]
2023-10-02 19:24:24,854 [1946070]   INFO - STDERR - Collecting outputs took 551[ms] and refresh took 604[ms]
2023-10-02 19:30:19,490 [2300706]   INFO - STDERR - Collecting outputs took 953[ms] and refresh took 7621[ms]
2023-10-02 19:31:08,210 [2349426]   INFO - STDERR - Collecting outputs took 660[ms] and refresh took 711[ms]

In IDEA, there is a non-recursive refresh with comment:

// refresh on output roots is required in order for the order enumerator to see all roots via VFS
                  // have to refresh in case of errors too, because run configuration may be set to ignore errors
                  CompilerUtil.refreshOutputRoots(affectedRoots);

which implies that we should probably do the same. Note: doing this will also address http://b/214033190 as it'll cause build dir to be loaded in VFS (as it's parent of javac/kotlinc/R.jar outputs).

This still implies that we need to move rendering off of VFS. It should be able to get the module roots using order enumerator, but it needs to use NIO to access actual bytes.

Data from doing a non-recursive, compiler outputs refresh. Again, we can cache outputs collection but the refresh needs to run synchronously. The project has 1000 subprojects:

For build that takes 4 seconds: Collecting outputs took 349[ms] and refresh took 2124[ms]
On full project clean that takes 800ms: Collecting outputs took 358[ms] and refresh took 1482[ms]

This is not great, we should try to figure out a way to do this only when needed.

One option is to monitor task execution, capture Gradle project paths for tasks that run, and do a refresh only for those modules. However, it does not help with running clean on the entire project as all modules are impacted.

Some findings:

1. com.intellij.openapi.roots.OrderEnumerator#classes returns only classes output roots that are in the VFS. I.e. until javac/kotlinc/R.jar dirs/files are actually created, they won't be returned by this API.

2. ProjectRootManagerComponent in IDEA gets all roots, but for classes it only gets the JPS classes output (for Android Studio, only javac output is registered). If javac output is added/removed, roots change event is triggered, which triggers RootIndex to be rebuilt and it triggeres scanning.

   2.1 Because of this, triggering synchronous compiler outputs refresh on build finished (in com.intellij.openapi.externalSystem.model.task.ExternalSystemTaskNotificationListener#onEnd) is a no-go.

3. GradleClassFileFinder uses ParameterizedCachedValueProvider that depends on ProjectSyncModificationTracker and ProjectBuildTracker. Also, it fetches module compiler outputs with GradleClassFinderUtil.getModuleCompileOutputs(it, includeAndroidTests) that returns File instances. This is important because of 1): we don't need to refresh VFS in order to get up-to-date information here.

4. Design previews already listen to build finished events, and they are able to trigger redraw in the right moment.

Because of issues outlined in 2.1) and because of how 3) works, my plan is to:

1. Trigger async compiler outputs refresh when build is done. This is to make sure users of OrderEnumerator#classes API are using up-to-date information.
2. Migrate com.android.tools.idea.projectsystem.ClassFileFinder#findClassFile to return byte array, as it is just used to feed classes to class loaders. We also need to handle jar files efficiently.

Done in ag/q/topic:%22class-finder%22.

We don't use VFS any more to load classes, bytes are loaded directly from disk. Also, extraction of R class final resources IDs is done with ASM (not PSI).

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Iguana | 2023.2.1 Canary 11
• Android Gradle Plugin 8.3.0-alpha11

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!