Feat: Introduce option and enhance non-interactive overloaded method handling#15
Open
Feat: Introduce option and enhance non-interactive overloaded method handling#15
Conversation
…-interactive mode - Added `-l` / `--list` flag to output available methods and exit without interactive prompts to save AI agent tokens. Implemented fail-fast logic (Exit Code 1) with available signatures when overloaded methods are requested in non-interactive environments (`System.console() == null`). - Enhanced MethodExtractor to support exact signature matching via JavaParser's `getDeclarationAsString`.
…rce quoting exact signatures for overloaded methods.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdded a non-interactive CLI option (-l/--list) to enumerate methods and exit; broadened method matching to include case-insensitive name or full declaration/signature matches; updated installer scripts' expected SHA256 checksums; documentation updated with usage and overload-handling guidance. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI as JFocusCli
participant Parser as FileParser
participant ME as MethodExtractor
User->>CLI: jfocus <file> -l
CLI->>Parser: parse file -> CompilationUnit
Parser-->>CLI: CompilationUnit
CLI->>ME: extractMethods(CompilationUnit, filter)
ME-->>CLI: list of method signatures
CLI-->>User: print method list and exit (0)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/main/java/com/jher235/jfocus/cli/JFocusCli.java (1)
46-72:⚠️ Potential issue | 🟠 Major
--listwithout a filename silently falls through to the interactive prompt instead of failing fast.The
listModeguard (line 69) sits after the interactivefileNamecollection loop (lines 46–53). When a user (or AI agent) runsjfocus -lwithout a filename:
- In a non-interactive environment:
scanner.nextLine()throwsNoSuchElementException, caught at line 129, and emits the unhelpful message"Critical Error: No line found".- In an interactive environment: the tool blocks waiting for a filename — defeating the non-interactive intent of
--list.🔧 Proposed fix — fail fast before the interactive loop
`@Override` public Integer call() { try { + // Fail fast: --list requires a file name upfront + if (listMode && (fileName == null || fileName.isEmpty())) { + System.err.println("Error: --list requires a file name. Usage: jfocus <file> -l"); + return 1; + } + // 1. Handle File Input (Interactive) while (fileName == null || fileName.isEmpty()) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/java/com/jher235/jfocus/cli/JFocusCli.java` around lines 46 - 72, The CLI currently prompts for a filename before checking listMode, causing blocking or NoSuchElementException when `--list` is used without a filename; update JFocusCli to perform the `listMode` guard before entering the interactive `fileName` loop: if `listMode` is true and `fileName` is null/empty, fail fast with a clear error message and return a non-zero exit code (instead of calling `scanner.nextLine()`), otherwise proceed to the existing interactive prompt, parsing (`ProjectParser.parseFile` / `cuOpt`) and calling `printMethodList(cu)` when appropriate; ensure you still support the normal flow when `fileName` is provided.scripts/install.ps1 (1)
1-1:⚠️ Potential issue | 🟡 MinorMissing UTF-8 BOM may corrupt emoji output in PowerShell 5.1.
The file uses non-ASCII emoji characters throughout (e.g., lines 19, 28, 34, 45). Without a UTF-8 BOM, PowerShell 5.1 (the default on Windows 10) defaults to ANSI encoding, which can display garbled characters or fail on systems where the default code page doesn't match. Save the file as UTF-8 with BOM (UTF-8-BOM) to ensure consistent rendering across all PowerShell versions.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/install.ps1` at line 1, This PowerShell script contains non-ASCII emoji characters (e.g., visible in the banner/header and subsequent comment lines) and must be saved with a UTF-8 BOM to avoid garbled output on PowerShell 5.1; open the script that begins with the header line "# ==========================================" (scripts/install.ps1) and re-save the file using "UTF-8 with BOM" (UTF-8-BOM) encoding in your editor/IDE or via an encoding-aware save command so PowerShell 5.1 will render emojis correctly.
♻️ Duplicate comments (1)
README.ko.md (1)
380-381: Same signature-format mismatch asREADME.mdline 374.The example
jfocus MyClass "add(int index, E element)"has the same correctness issue documented inREADME.md. Update in tandem once theMethodExtractor.javafix is applied.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.ko.md` around lines 380 - 381, The Korean README example uses a method signature format that doesn't match the canonical signature expected by MethodExtractor.java; update the example invocation (the `jfocus MyClass "add(int index, E element)"` line) to the exact signature format MethodExtractor.java recognizes (the same corrected form you will apply in README.md line 374) so the guidance and example are consistent with `MethodExtractor.java`'s parsing rules and the `jfocus` usage instructions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/rules.md`:
- Around line 15-18: The example signature in docs/rules.md doesn't match what
MethodExtractor.extractMethods recognizes; update the example to the format
produced by MethodExtractor's current call to getDeclarationAsString(false,
false, false) (e.g., "void add(int, E)") so the docs and the overload error
format align with extractMethods; if you later change MethodExtractor to call
getDeclarationAsString(false, false, true), then update the example to the new
format (e.g., "void add(int index, E element)").
In `@README.md`:
- Around line 374-375: The README example uses parameter names but
MethodExtractor.extractMethods matches signatures using
getDeclarationAsString(false,false,false) or getSignature().asString(), which
produce forms like "void add(int, E)" or "add(int, E)"; update the documented
example to show the actual matching format (e.g., jfocus MyClass "add(int, E)"
or include return type "void add(int, E)") or change
MethodExtractor.extractMethods to normalize/accept parameter names; reference
MethodExtractor.extractMethods, getDeclarationAsString(false, false, false), and
getSignature().asString() when making the change so the doc and matching logic
align.
In `@src/main/java/com/jher235/jfocus/cli/JFocusCli.java`:
- Around line 219-232: printMethodList currently builds parameter text by
mutating m.getParameters().toString(), which corrupts array types; instead call
MethodDeclaration.getDeclarationAsString(false, false, true) on each
MethodDeclaration m and use that declaration (or extract the parenthesized
parameter substring from it) when printing; update the loop in printMethodList
to replace the bracket-replacement hack with this API so array types like int[]
are preserved correctly.
In `@src/main/java/com/jher235/jfocus/core/MethodExtractor.java`:
- Around line 19-22: Method matching fails to recognize the same signature
format printed by printMethodList/README because MethodExtractor currently
compares methodName against getDeclarationAsString(false,false,false) and
getSignature().asString() which omit parameter names; standardize on
getDeclarationAsString(false,false,true) everywhere: update MethodExtractor's
filter to compare methodName to method.getDeclarationAsString(false,false,true)
(and remove/stop relying on getSignature().asString()), update JFocusCli's
overload error message (the string at the reported line) to use
getDeclarationAsString(false,false,true), and change printMethodList to print
method.getDeclarationAsString(false,false,true) so listing, matching, and error
messages all use the identical "returnType name(paramType paramName, ...)"
format.
---
Outside diff comments:
In `@scripts/install.ps1`:
- Line 1: This PowerShell script contains non-ASCII emoji characters (e.g.,
visible in the banner/header and subsequent comment lines) and must be saved
with a UTF-8 BOM to avoid garbled output on PowerShell 5.1; open the script that
begins with the header line "# =========================================="
(scripts/install.ps1) and re-save the file using "UTF-8 with BOM" (UTF-8-BOM)
encoding in your editor/IDE or via an encoding-aware save command so PowerShell
5.1 will render emojis correctly.
In `@src/main/java/com/jher235/jfocus/cli/JFocusCli.java`:
- Around line 46-72: The CLI currently prompts for a filename before checking
listMode, causing blocking or NoSuchElementException when `--list` is used
without a filename; update JFocusCli to perform the `listMode` guard before
entering the interactive `fileName` loop: if `listMode` is true and `fileName`
is null/empty, fail fast with a clear error message and return a non-zero exit
code (instead of calling `scanner.nextLine()`), otherwise proceed to the
existing interactive prompt, parsing (`ProjectParser.parseFile` / `cuOpt`) and
calling `printMethodList(cu)` when appropriate; ensure you still support the
normal flow when `fileName` is provided.
---
Duplicate comments:
In `@README.ko.md`:
- Around line 380-381: The Korean README example uses a method signature format
that doesn't match the canonical signature expected by MethodExtractor.java;
update the example invocation (the `jfocus MyClass "add(int index, E element)"`
line) to the exact signature format MethodExtractor.java recognizes (the same
corrected form you will apply in README.md line 374) so the guidance and example
are consistent with `MethodExtractor.java`'s parsing rules and the `jfocus`
usage instructions.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
README.ko.mdREADME.mddocs/rules.mdscripts/install.ps1scripts/install.shsrc/main/java/com/jher235/jfocus/cli/JFocusCli.javasrc/main/java/com/jher235/jfocus/core/MethodExtractor.java
README.md
Outdated
Comment on lines
374
to
375
| > **Note on Overloaded Methods:** If a method requires specifying parameters to resolve an overload (e.g. `add(int, E)`), be sure to configure the agent to wrap the exact signature in quotes (e.g., `jfocus MyClass "add(int index, E element)"`) to prevent shell syntax errors. | ||
|
|
There was a problem hiding this comment.
Documented signature format doesn't match the actual matching logic.
The example jfocus MyClass "add(int index, E element)" includes parameter names. However, extractMethods in MethodExtractor.java matches via:
getDeclarationAsString(false, false, false)→ producesvoid add(int, E)(return type + param types only, no param names)getSignature().asString()→ producesadd(int, E)(no return type, no param names)
Neither matches "add(int index, E element)", so the documented usage won't resolve the overload. See the root-cause comment on MethodExtractor.java for a proposed fix.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 374 - 375, The README example uses parameter names
but MethodExtractor.extractMethods matches signatures using
getDeclarationAsString(false,false,false) or getSignature().asString(), which
produce forms like "void add(int, E)" or "add(int, E)"; update the documented
example to show the actual matching format (e.g., jfocus MyClass "add(int, E)"
or include return type "void add(int, E)") or change
MethodExtractor.extractMethods to normalize/accept parameter names; reference
MethodExtractor.extractMethods, getDeclarationAsString(false, false, false), and
getSignature().asString() when making the change so the doc and matching logic
align.
- Replaced hacky regex bracket replacements with JavaParser's native `getDeclarationAsString(false, false, true)`. - Standardized method signature outputs across `--list`, interactive mode, and overload error messages to uniformly include return types and parameter names (e.g., `void add(int index, E element)`). - Updated `MethodExtractor.java` to exact-match using the same standardized format. - Fixed documentation (`README`, `rules.md`) to reflect the new signature matching format.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
README.ko.md (1)
376-380:⚠️ Potential issue | 🟡 MinorAlign the overload example with the exact signature format.
The example
add(int, E)omits the return type, but the required format now includes it.✏️ Suggested wording alignment
-> **오버로딩 메서드 주의사항:** 오버로딩된 메서드를 분석할 때 매개변수를 지정해야 한다면 (예: `add(int, E)`), 셸 문법 오류를 방지하기 위해 에이전트가 정확한 시그니처를 **반드시 따옴표로 감싸도록** (예: `jfocus MyClass "void add(int index, E element)"`) 규칙을 설정해 주세요. +> **오버로딩 메서드 주의사항:** 오버로딩된 메서드를 분석할 때 매개변수를 지정해야 한다면 (예: `void add(int index, E element)`), 셸 문법 오류를 방지하기 위해 에이전트가 정확한 시그니처를 **반드시 따옴표로 감싸도록** (예: `jfocus MyClass "void add(int index, E element)"`) 규칙을 설정해 주세요.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.ko.md` around lines 376 - 380, Update the overload example to include the full method signature with return type and parameter names (e.g., replace the current shorthand add(int, E) with a full signature like "void add(int index, E element)"), and adjust the rule text so the jfocus usage demonstrates quoting the entire signature (e.g., jfocus MyClass "void add(int index, E element)") to match the required format; ensure the README's sentence that warns about quoting when analyzing overloaded methods references PaymentService.process() only as an example context and reflects the new signature format requirement.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/rules.md`:
- Around line 11-16: Change the indefinite article before the error name
"Multiple overloads found" from "an" to "a" in the Command Usage (CRITICAL)
section; specifically update the sentence that currently reads 'If JFocus
returns an "Multiple overloads found" error...' to read 'If JFocus returns a
"Multiple overloads found" error...'; also scan the same document for any other
occurrences of the exact error string and correct their articles to "a" as well.
---
Outside diff comments:
In `@README.ko.md`:
- Around line 376-380: Update the overload example to include the full method
signature with return type and parameter names (e.g., replace the current
shorthand add(int, E) with a full signature like "void add(int index, E
element)"), and adjust the rule text so the jfocus usage demonstrates quoting
the entire signature (e.g., jfocus MyClass "void add(int index, E element)") to
match the required format; ensure the README's sentence that warns about quoting
when analyzing overloaded methods references PaymentService.process() only as an
example context and reflects the new signature format requirement.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
README.ko.mdREADME.mddocs/rules.mdsrc/main/java/com/jher235/jfocus/cli/JFocusCli.java
🚧 Files skipped from review as they are similar to previous changes (1)
- README.md
Comment on lines
11
to
16
| 2. **Command Usage (CRITICAL)**: | ||
| - **NEVER use `jfocus <file>` without `-l` or a method name.** It triggers an interactive prompt that will cause you (the agent) to hang/timeout. | ||
| - `jfocus <file> -l` : Lists available methods in the file non-interactively. Always use this instead of reading the entire file to save tokens. | ||
| - `jfocus <file> <method>` : Extracts context for the method. | ||
| - If JFocus returns an "Multiple overloads found" error, it will also print the exact available signatures. You MUST retry using the EXACT signature. | ||
| - **CRITICAL:** When specifying an exact method signature with parameters (like `void add(int index, E element)`), you MUST wrap the method name in quotes to prevent Bash syntax errors. |
There was a problem hiding this comment.
Fix the article before the error name.
Use “a” instead of “an” before “Multiple overloads found.”
✏️ Proposed doc tweak
- - If JFocus returns an "Multiple overloads found" error, it will also print the exact available signatures. You MUST retry using the EXACT signature.
+ - If JFocus returns a "Multiple overloads found" error, it will also print the exact available signatures. You MUST retry using the EXACT signature.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| 2. **Command Usage (CRITICAL)**: | |
| - **NEVER use `jfocus <file>` without `-l` or a method name.** It triggers an interactive prompt that will cause you (the agent) to hang/timeout. | |
| - `jfocus <file> -l` : Lists available methods in the file non-interactively. Always use this instead of reading the entire file to save tokens. | |
| - `jfocus <file> <method>` : Extracts context for the method. | |
| - If JFocus returns an "Multiple overloads found" error, it will also print the exact available signatures. You MUST retry using the EXACT signature. | |
| - **CRITICAL:** When specifying an exact method signature with parameters (like `void add(int index, E element)`), you MUST wrap the method name in quotes to prevent Bash syntax errors. | |
| 2. **Command Usage (CRITICAL)**: | |
| - **NEVER use `jfocus <file>` without `-l` or a method name.** It triggers an interactive prompt that will cause you (the agent) to hang/timeout. | |
| - `jfocus <file> -l` : Lists available methods in the file non-interactively. Always use this instead of reading the entire file to save tokens. | |
| - `jfocus <file> <method>` : Extracts context for the method. | |
| - If JFocus returns a "Multiple overloads found" error, it will also print the exact available signatures. You MUST retry using the EXACT signature. | |
| - **CRITICAL:** When specifying an exact method signature with parameters (like `void add(int index, E element)`), you MUST wrap the method name in quotes to prevent Bash syntax errors. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/rules.md` around lines 11 - 16, Change the indefinite article before the
error name "Multiple overloads found" from "an" to "a" in the Command Usage
(CRITICAL) section; specifically update the sentence that currently reads 'If
JFocus returns an "Multiple overloads found" error...' to read 'If JFocus
returns a "Multiple overloads found" error...'; also scan the same document for
any other occurrences of the exact error string and correct their articles to
"a" as well.
- Standardized the exact method signature example to include the return type and parameter names (e.g., `void add(int index, E element)`) to match the actual `MethodExtractor` matching logic.
- Fixed a minor grammatical error ("an" -> "a" before "Multiple overloads found").
- Updated `rules.md` to provide AI agents with flexible tool-selection strategies, advising them to use `jfocus` for method-level logic, but permitting full-file reads for class-level structures and fields to prevent hallucinations.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/rules.md`:
- Around line 16-17: The examples for the jfocus command use a bare class name
(MyClass) which can be mistaken for a class rather than a file path; update the
concrete examples in docs/rules.md so they include the .java extension (e.g.,
change occurrences like `jfocus MyClass "void add(int index, E element)"` and
`jfocus MyClass void add(int index, E element)` to `jfocus MyClass.java "void
add(int index, E element)"` and `jfocus MyClass.java void add(int index, E
element)`), ensuring any other examples showing `MyClass` are similarly changed
so the tool receives a file path not just a class name.
- Changed `getDeclarationAsString(false, false, false)` to `getDeclarationAsString(false, false, true)` in `MethodExtractor.java`. - This ensures the internal signature matching logic perfectly aligns with the CLI's output format (including parameter names), fixing a critical bug where heavily specific method lookups (e.g. `ContextResult extractContext(MethodDeclaration targetMethod)`) were being falsely rejected as "Not found".
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/rules.md`:
- Around line 10-18: Update the docs/rules.md text to replace ambiguous uses of
"method name" with "method signature" so it's clear you must quote the full
signature when specifying overloads; specifically change the bullet that
currently reads "**CRITICAL:** When specifying an exact method signature with
parameters (like `void add(int index, E element)`), you MUST wrap the method
name in quotes..." to reference "method signature" and ensure the examples use
"method signature" (e.g., `jfocus src/main/java/MyClass.java "void add(int
index, E element)"`) and the incorrect example still demonstrates unquoted
signature to prevent ambiguity.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
README.ko.mdREADME.mddocs/rules.mdsrc/main/java/com/jher235/jfocus/core/MethodExtractor.java
✅ Files skipped from review due to trivial changes (1)
- README.ko.md
🚧 Files skipped from review as they are similar to previous changes (1)
- README.md
Comment on lines
+10
to
+18
| 2. **Command Usage (CRITICAL)**: | ||
| - **NEVER use `jfocus <file>` without `-l` or a method name.** It triggers an interactive prompt that will cause you (the agent) to hang/timeout. | ||
| - **NEVER use just a class name for the `<file>` argument.** Using just `MyClass` will trigger a "Multiple files found" prompt if duplicates exist. **ALWAYS use a specific relative or absolute path** (e.g., `src/main/java/com/pkg/MyClass.java`). | ||
| - `jfocus <path/to/file.java> -l` : Lists available methods in the file non-interactively. | ||
| - `jfocus <path/to/file.java> <method>` : Extracts context for the method. | ||
| - If JFocus returns a "Multiple overloads found" error, it will also print the exact available signatures. You MUST retry using the EXACT signature. | ||
| - **CRITICAL:** When specifying an exact method signature with parameters (like `void add(int index, E element)`), you MUST wrap the method name in quotes to prevent Bash syntax errors. | ||
| - Correct: `jfocus src/main/java/MyClass.java "void add(int index, E element)"` | ||
| - Incorrect: `jfocus src/main/java/MyClass.java void add(int index, E element)` |
There was a problem hiding this comment.
Clarify “method name” → “signature” to avoid ambiguity.
Line 16 asks to quote the method name, but the examples and intent are about quoting the full signature.
✏️ Proposed doc tweak
- - **CRITICAL:** When specifying an exact method signature with parameters (like `void add(int index, E element)`), you MUST wrap the method name in quotes to prevent Bash syntax errors.
+ - **CRITICAL:** When specifying an exact method signature with parameters (like `void add(int index, E element)`), you MUST wrap the entire signature in quotes to prevent Bash syntax errors.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/rules.md` around lines 10 - 18, Update the docs/rules.md text to replace
ambiguous uses of "method name" with "method signature" so it's clear you must
quote the full signature when specifying overloads; specifically change the
bullet that currently reads "**CRITICAL:** When specifying an exact method
signature with parameters (like `void add(int index, E element)`), you MUST wrap
the method name in quotes..." to reference "method signature" and ensure the
examples use "method signature" (e.g., `jfocus src/main/java/MyClass.java "void
add(int index, E element)"`) and the incorrect example still demonstrates
unquoted signature to prevent ambiguity.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📝 Description
This Pull Request introduces significant enhancements to
jfocusto improve its usability, particularly for AI agents and non-interactive environments. Previously,jfocuscould lead to agent hangs when invoked without a specific method name (triggering an interactive prompt) or when encountering overloaded methods without an exact signature.To address these issues, a new
--listoption has been added, allowing users and agents to retrieve available methods non-interactively and efficiently, optimizing token usage. Furthermore, the tool now implements a fail-fast mechanism for overloaded methods in non-interactive contexts, providing clear error messages with available signatures instead of hanging. This change, coupled with enhanced signature matching, ensures more robust and predictable behavior.Accompanying these functional changes, the documentation (READMEs and agent rules) has been thoroughly updated to guide users and agents on the correct usage of the new
--listflag and the critical requirement of quoting exact method signatures to prevent shell syntax errors and ensure precise method resolution. Finally, the installation script checksums have been updated for security.✨ What does this PR do?
--list(-l) CLI option: Allows users and AI agents to list all available methods in a specified Java file non-interactively and exit cleanly, optimizing token usage and preventing interactive prompts in automated workflows.jfocuswill now exit with an error (Exit Code 1) and provide a list of available exact signatures, preventing hangs and guiding users/agents to correct usage.MethodExtractorto support exact signature matching: Improves the precision of method identification by leveraging JavaParser'sgetDeclarationAsStringfor robust resolution of overloaded methods.README.md,README.ko.md, anddocs/rules.md:--listflag and its usage.-lwhen listing methods and to quote exact method signatures for overloaded methods to avoid shell syntax errors and ensure correct parsing.jfocus <file>without-lor a method name, as it causes interactive prompts that can hang agents.j-focusjar in the installation scripts (install.ps1,install.sh).Summary by CodeRabbit
New Features
Documentation
Chores