IssueTracker

Hey, can you please try these steps to help me debug the file lock?

1- Download the file leak detector (https://file-leak-detector.kohsuke.org/)

2- Check with resmon what process is holding on to the file

3- Depending on where the file is locked, do the following: Studio- In studio, go to help -> edit custom vm options and add the following line: -javaagent:path/to/file-leak-detector.jar=http=19999 AGP/Other- Add to your gradle.properties file the following line (replace the path with the correct one): org.gradle.jvmargs=-javaagent:path/to/file-leak-detector.jar=http=19999

4- When the problem occurs again, open localhost:199999 in your browser. This is the report generated by the file leak detector. Copy the text into a text file and attach it to your bug report.

Great tip about using file-leak-detector! I'm having the same problem and apparently R.jar and many other things are being held because I am using AspectJ:

#115 C:\Users\me\StudioProjects\myapp\app\build\intermediates\compile_and_runtime_not_namespaced_r_class_jar\debug\R.jar by thread:Execution worker for ':' Thread 3 on Mon Oct 19 18:41:06 BST 2020
    at java.util.zip.ZipFile.<init>(ZipFile.java:156)
    at java.util.zip.ZipFile.<init>(ZipFile.java:169)
    at org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJar.ensureOpen(ClasspathJar.java:405)
    at org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:246)
    at org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJar.fetchLinkedJars(ClasspathJar.java:104)
    at org.aspectj.org.eclipse.jdt.internal.compiler.batch.Main.handleClasspath(Main.java:3800)
    at org.aspectj.ajdt.ajc.BuildArgParser.handleClasspath(BuildArgParser.java:394)
    at org.aspectj.org.eclipse.jdt.internal.compiler.batch.Main.setPaths(Main.java:5335)
    at org.aspectj.org.eclipse.jdt.internal.compiler.batch.Main.configure(Main.java:3285)
    at org.aspectj.ajdt.ajc.BuildArgParser.populateBuildConfig(BuildArgParser.java:180)
    at org.aspectj.ajdt.ajc.BuildArgParser.genBuildConfig(BuildArgParser.java:121)
    at org.aspectj.ajdt.ajc.AjdtCommand.genBuildConfig(AjdtCommand.java:147)
    at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:99)
    at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:60)
    at org.aspectj.tools.ajc.Main.run(Main.java:371)
    at org.aspectj.tools.ajc.Main$run.call(Unknown Source)
    at build_1cezq4lsi80n5l5nxgaddlnzx.weaveCats(C:\Users\me\StudioProjects\myapp\app\build.gradle:181)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
    at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:351)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:64)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:184)
    at build_1cezq4lsi80n5l5nxgaddlnzx$_run_closure7.doCall(C:\Users\me\StudioProjects\myapp\app\build.gradle:237)
    at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
    at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:263)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
    at groovy.lang.Closure.call(Closure.java:405)
    at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:41)
    at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:25)
    at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:43)
    at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:245)
    at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:157)
    at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:61)
    at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:346)
    at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:249)
    at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:141)
    at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
    at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
    at com.sun.proxy.$Proxy100.afterExecute(Unknown Source)
    at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:91)
    at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
    at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
    at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:76)
    at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
    at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:76)
    at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
    at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:41)
    at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:372)
    at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:359)
    at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:352)
    at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:338)
    at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
    at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
    at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
    at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
    at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
    at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
    at java.lang.Thread.run(Thread.java:748)

Note the line with build_1cezq4lsi80n5l5nxgaddlnzx.weaveCats() in the stack trace, which is this code:

def weaveCats(String classPath, String aspectPath, String inputOutput) {
    String[] args = [
            "-showWeaveInfo",
            "-1.8",
            "-inpath", inputOutput,
            "-aspectpath", aspectPath,
            "-d", inputOutput,
            "-classpath", classPath,
            "-bootclasspath", android.bootClasspath.join(File.pathSeparator)
    ]

    MessageHandler handler = new MessageHandler(true)
    new Main().run(args, handler)

    def log = project.logger
    for (IMessage message : handler.getMessages(null, true)) {
        switch (message.getKind()) {
            case IMessage.ABORT:
            case IMessage.ERROR:
            case IMessage.FAIL:
                log.error "ERROR: " + message.message, message.thrown
                break
            case IMessage.WARNING:
                log.warn "WARN: " + message.message, message.thrown
                break
            case IMessage.INFO:
                log.info "INFO: " + message.message, message.thrown
                break
            case IMessage.DEBUG:
                log.info "DEBUG " + message.message, message.thrown
                break
        }
    }
}

I'm not quite sure how to resolve this, but at least I now know the source of the issue!

If the issue is with another component/plugin, I suggest you file a bug with them about their software holding on to file handles

I'm not OP so they might have a different issue. I only posted this as AspectJ is a rather common tool and other people might be having issues with it.

I resolved the issue by running the weaver in a separate process. I added a new configuration to get aspectjtools on classpath:

val weaving: Configuration by configurations.creating

dependencies {
    weaving("org.aspectj:aspectjtools:1.9.6")
}

and instead of doing Main().run(..) I'm calling

javaexec {
    classpath = weaving
    main = "org.aspectj.tools.ajc.Main"
    args = arguments
}

please try the leak detector described in comment #3

Having the same issue with the following configuration:

Android Studio Arctic Fox | 2020.3.1 Canary 8
Build #AI-203.7148.57.2031.7165533, built on February 23, 2021
Runtime version: 11.0.8+10-b944.6842174 amd64
VM: OpenJDK 64-Bit Server VM by N/A
Windows 10 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 4096M
Cores: 32
Registry: external.system.auto.import.disabled=true
Non-Bundled Plugins: Key Promoter X, Docker, com.pspdfkit.androidstudio-plugin, org.intellij.plugins.markdown

Windows Resource Monitor does not show the R.jar file as locked/opened by any process. Also, the File Leak Detector does not show any leaks (Report is: "0 descriptors are open"). I can manually remove the R.jar file using the Windows Explorer or using Android Studio, so the file seems not locked.

The issue also happens when disabling Gradle daemons by adding org.gradle.daemon=false to the project's gradle.properties.

The issue does not happen when building the Compose app's :app module, but only when trying to deploy the composable preview.

Android Studio Arctic Fox | 2020.3.1 Canary 8
Build #AI-203.7148.57.2031.7165533, built on February 23, 2021
Runtime version: 11.0.8+10-b944.6842174 amd64
VM: OpenJDK 64-Bit Server VM by N/A
Windows 10 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 10240M
Cores: 16
Registry: external.system.auto.import.disabled=true
Non-Bundled Plugins: String Manipulation, indent-rainbow.indent-rainbow, org.sylfra.idea.plugins.linessorter, com.longforus.kotlincodesorter, izhangzhihao.rainbow.brackets, org.intellij.plugins.markdown

After removing all the *.xml files from the directory %USERPROFILE%\AppData\Roaming\Google\AndroidStudioPreview2020.3\workspace, the problem seems to be gone.

Some Problem here (blocker) with

Android Studio Arctic Fox | 2020.3.1 Patch 2
Build #AI-203.7717.56.2031.7678000, built on August 26, 2021
Runtime version: 11.0.10+0-b96-7249189 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.4.0-84-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 4
Registry: external.system.auto.import.disabled=true
Non-Bundled Plugins: org.jetbrains.kotlin
Current Desktop: MATE

happens more often if the project files build folder is on a network mount. We cannot delete the file (the same R.jar) nor overwrite as it claims to be not there and there at the time time. Rather typical issues for holding a lock (cifs mount on linux [sorry, no way to avoid that]).

$ ll app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug/R.jar 
-rwx------...  992149 Okt  5 14:20 app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug/R.jar
$ rm app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug/R.jar 
rm: Normale Datei 'app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug/R.jar' entfernen? y
rm: das Entfernen von 'app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug/R.jar' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
$ ll app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug/R.jar 
-rwx------ ... 992149 Okt  5 14:20 app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug/R.jar

I have disabled the gradle daemon, no help. The only java that is running is the java bundled with the IDE.

Same issue on Linux on NFSV4 mount

Unable to delete directory '/home/media/share/ToggleApp/app/build'
  Failed to delete some children. This might happen because a process has files open or has its working directory set in the target directory.
  - /home/media/share/ToggleApp/app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug
  - /home/media/share/ToggleApp/app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar
  - /home/media/share/ToggleApp/app/build/intermediates

when rebuilding

I don't even use Compose yet and I see this issue. It has existed for a very long time. Maybe even before Compose was offered on the IDE.

I believe this is caused by jar caching in intellij (https://github.com/JetBrains/intellij-community/blob/2938946086cfcd264bac8d82ec3241c45c40b57d/platform/core-impl/src/com/intellij/openapi/vfs/impl/ZipHandler.java#L15), and that this causes issues on:

• Windows because handles are not released properly - https://github.com/JetBrains/intellij-community/blob/8f0275fd7faaeafdb8900147eab3d256fe4221cb/platform/platform-impl/src/com/intellij/openapi/vfs/impl/jar/TimedZipHandler.java#L67
• non-Windows operating systems that use network drives e.g nfsv4 - filed as https://youtrack.jetbrains.com/issue/IDEA-284000

We should understand if this is a platform issue or we are using these APIs in a way they were not designed for.

Re #18: This is not compose-specific, but it is related to any kind of UI rendering done by design tools.

@20 I don't think I had a design tool opened. Just the IDE's text editor.

Described issue with "R.jar" is happening to me quite often … no matter if I want to launch MainActivity or Compose Preview or if Preview pane shown or not.

Killing all java processes didn't help.

Rebuild Project action helps with this, but this "workaround" makes IDE for Android development quite useless.

Environment: Windows 10 and these Android Studio versions:

• Android Studio Arctic Fox | 2020.3.1 Patch 4
• Android Studio Bumblebee | 2021.1.1 Beta 5

In IntelliJ IDEA 2021.3 (Ultimate Edition) with Android plugin on same machine, this issue is not present so far.

This has been fixed by IntelliJ for local "R.jar" files in Windows machines and the is available in the newer versions of Studio. However the issue will still present for the cases where the R.jar is in a network disk.

As for me the issue suddenly appeared again. I updated studio to latest version but problem is still actual. My work completely stopped!

Studio + emulator Pixel_3a_API30_(Android11):

Android Studio Bumblebee | 2021.1.1
Build #AI-211.7628.21.2111.8092744, built on January 19, 2022
Runtime version: 11.0.11+9-b60-7590822 amd64
VM: OpenJDK 64-Bit Server VM by Oracle Corporation
Windows 10 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 4096M
Cores: 16
Registry: external.system.auto.import.disabled=true
Non-Bundled Plugins: com.github.akiacode.copilot (0.0.1), wu.seal.tool.jsontokotlin (3.7.2), com.thoughtworks.gauge (211.6693.111), org.jetbrains.kotlin (211-1.6.10-release-923-AS7442.40), org.intellij.plugins.markdown (211.7142.37)

What release is this going to be in?

This has made programming with Jetpack Compose unbearable. Even an empty project that has no activity can't run one composable preview after another. I have to close the IDE, then reopen it to see my minor changes.

Running taskkill /im java.exe /f in command prompt doesn't seem to help. Closing OpenJDK Platform binary from the task manager seems to work intermittently.

I never used compose but this issue is coming up every single day, right now I'm trying an almost empty project in Chipmunk and getting the following when pressing the "Hammer" to build the project.

* What went wrong:
Execution failed for task ':...:generateDebugRFile'.
java.nio.file.FileSystemException: C:\...\build\intermediates\compile_r_class_jar\debug\R.jar: The process cannot access the file because it is being used by another process.

I tried to install leak detector but so far "0" and while installing it, the issue disappeared 🤦‍♂️.

Windows 10, no network mount, but not C:\ either, on secondary partition.

di... #23 what's "newer version"? C, D, E?

Is this fixed?!

I'm currently running the same project on both (Cheipmunck | 2021.2.1 Patch 2) and (Electric Eel | 2022.1.1 Canary 9).

It still happens on Checipmunck but when following the same steps on Electric Eel, this issue does not show up.

Edit: the issue accord again!

Have you tried Electric Eel | 2022.1.1 Canary 9? it was released a week ago.

@37 The same on Android Studio Dolphin | 2021.3.1 Patch 1

This often happens to me, too. I've encountered this on different Android Studio versions, both stable and canary builds. The latest version I'm using now (which still has this problem) is:

Android Studio Hedgehog | 2023.1.1 Canary 2
Build #AI-231.6890.12.2311.10027519, built on April 28, 2023
Runtime version: 17.0.6+0-b2043.56-9884540 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 4096M
Cores: 12
Registry:
    external.system.auto.import.disabled=true
    debugger.new.tool.window.layout=true
    ide.text.editor.with.preview.show.floating.toolbar=false
    ide.experimental.ui=true

It's pretty annoying especially when it happens twice in a row. Like, when I try to build my app, I would encounter this. Then, I would exit and restart the IDE then try to rebuild my app and the issue would still happen. I often have to keep restarting the IDE which wastes my time.

Re #45: It seems like you are hitting https://issuetracker.google.com/277166577, which also has a workaround in https://issuetracker.google.com/277166577#comment6.

Android Studio Giraffe | 2022.3.1 Patch 1 Build #AI-223.8836.35.2231.10671973, built on August 17, 2023 Runtime version: 17.0.6+0-b2043.56-10027231 amd64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.

still have this bug

probably a duplicate of 276852967 and many others, Diego, can we get someone to look at this ? there are already 83 votes on this one.

Jerome, b/276852967 seems to indicate than killing child JVMs resolves the problem. That would indicate that the problem in b/276852967 is probably not Preview related since the Preview lives in the Studio JVM. Might be a different root cause.

For everyone still having this issue, could you please confirm if killing all the child processes of Android Studio (without having to kill Android Studio) helps also in your case? Thanks!

There seems to be 2 file leaks, one is probably in the Android Gradle plugin (Gradle daemon JVM) that's tracked in https://issuetracker.google.com/276852967, and there is probably a leak in the design tools that's tracked in this bug.

For those of you who are seeing this issue on Studio H and Studio I, can you please try to follow these instructions and share your findings:

1. Download the file leak detector (https://github.com/jenkinsci/lib-file-leak-detector#download)

2. Check with "Resource Monitor" what process is holding onto the file. See https://superuser.com/a/643312 for instructions.

3. File can be locked by Android Studio or Gradle, as they run in 2 separate JVM processes. Depending on where the file is locked, do the following:

   • Studio - In studio, go to help -> edit custom vm options and add the following line: -javaagent:path/to/file-leak-detector.jar=http=19999
   • Gradle (i.e. AGP or other plugins) - Add to your gradle.properties file the following line (replace the path with the correct one): org.gradle.jvmargs=-javaagent:path/to/file-leak-detector.jar=http=19999

4. When the problem occurs again, open localhost:199999 in your browser. This is the report generated by the file leak detector. Copy the text into a text file and attach it to the bug report. In case the issue is in Studio please upload your report to https://issuetracker.google.com/167701947. In case the issue is in Gradle please upload it to https://issuetracker.google.com/276852967.

Thanks!

Re #61: I've just updated #60, please try using https://github.com/jenkinsci/lib-file-leak-detector#download to download the jar.

For me it's the java.exe process that is using the R.jar file in the build, when I kill the process I can clean the project, but it seems that I have to do it everytime I run the app as the java.exe restarts and uses the R.jar.

Execution failed for task ':app:processDebugResources'.

A failure occurred while executing com.android.build.gradle.internal.res.LinkApplicationAndroidResourcesTask$TaskAction C:\Users...\app\build\intermediates\compile_and_runtime_not_namespaced_r_class_jar\debug\R.jar: The process cannot access the file because it is being used by another process

Hello, I write a python script to close R.jar file handle, deps python3, pslist and handle64, the last two exe can download from https://download.sysinternals.com/files/SysinternalsSuite.zip, then unzip and add to path, then run this script as admin

main.py

import os
import subprocess


class Process:
    def __init__(self, name, pid):
        self.name = name
        self.pid = pid


class HandleFile:
    def __init__(self, name, pid, handleId):
        self.name = name
        self.pid = pid
        self.handleId = handleId


if __name__ == '__main__':
    taskResult = os.popen("pslist | findstr java")
    str = taskResult.read()
    tasks = str.split('\n')
    javaProcesses = []
    for task in tasks:
        if len(task) != 0:
            taskNamePid = task.split()
            javaProcesses.append(Process(taskNamePid[0], taskNamePid[1]))
    r_jarHandles = []
    for javaProcess in javaProcesses:
        handleResult = os.popen(f"handle64 -p {javaProcess.pid}| findstr R.jar")
        handleResultStr = handleResult.read()
        if len(handleResultStr) != 0:
            handleResultStrFile = handleResultStr.split(":")
            r_jarHandles.append(HandleFile("R.jar", javaProcess.pid, handleResultStrFile[0]))

    for r_jarHandle in r_jarHandles:
        print(f"{r_jarHandle.name} {r_jarHandle.pid} {r_jarHandle.handleId}")
        result = os.popen(f"handle64  -c {r_jarHandle.handleId} -p {r_jarHandle.pid} -y")
        print(result.read())

I hope this python script can save our time

God bless us