Summary
jar tf, jar xf, and javap are not intercepted by RTK. These commands produce large, verbose output when inspecting JVM class files and JAR archives — common during Android/JVM dependency debugging.
Usage data
From rtk discover on an Android monorepo project (last 30 days):
- 27 invocations of
jar xf
- 13 invocations of
jar tf
- 11 invocations of
javap
Example commands seen:
jar tf /tmp/classes.jar
jar xf /Users/sinan.kozak/.gradle/caches/modules-2/files-2.1/com.bumptech.glide/...
javap -p com/bumptech/glide/integration/compose/ExperimentalGlideComposeApi.class
Why it matters
jar tf lists every class file in a JAR — large libraries (e.g. Glide, OkHttp) can have thousands of entriesjar xf extracts files and is often followed by inspecting extracted contentjavap -p dumps full decompiled bytecode including all method signatures
All three produce output that is largely noise for the model — it typically only needs a few specific class names or method signatures, not the full listing.
Expected behavior
rtk jar tf <jar> — truncate output, show first N entries + summary count ("showing 50 of 3,241 classes")rtk javap <args> — truncate to relevant sections, similar to how RTK handles large grep outputrtk jar xf — passthrough (extraction itself produces no stdout, follow-up reads are handled by rtk read)
Current workaround
Pipe through grep manually: jar tf foo.jar | grep SomeClass — but this requires knowing what to grep for upfront.
Summary
jar tf,jar xf, andjavapare not intercepted by RTK. These commands produce large, verbose output when inspecting JVM class files and JAR archives — common during Android/JVM dependency debugging.Usage data
From
rtk discoveron an Android monorepo project (last 30 days):jar xfjar tfjavapExample commands seen:
Why it matters
jar tflists every class file in a JAR — large libraries (e.g. Glide, OkHttp) can have thousands of entriesjar xfextracts files and is often followed by inspecting extracted contentjavap -pdumps full decompiled bytecode including all method signaturesAll three produce output that is largely noise for the model — it typically only needs a few specific class names or method signatures, not the full listing.
Expected behavior
rtk jar tf <jar>— truncate output, show first N entries + summary count ("showing 50 of 3,241 classes")rtk javap <args>— truncate to relevant sections, similar to how RTK handles large grep outputrtk jar xf— passthrough (extraction itself produces no stdout, follow-up reads are handled byrtk read)Current workaround
Pipe through
grepmanually:jar tf foo.jar | grep SomeClass— but this requires knowing what to grep for upfront.