feat: add Copilot Java quick assist

[Yutong Lyu (lytreallynb)]

Summary

• Add a JDT quick assist that offers Suggest fix with GitHub Copilot for problem markers overlapping the caret or current selection.
• Deduplicate diagnostics in source order and prefill the existing Copilot Chat flow without automatically sending the prompt.
• Hide the proposal while Copilot is signed out or still initializing.

This intentionally limits the initial implementation to org.eclipse.jdt.ui.quickAssistProcessors, as agreed in the issue discussion.

Testing

• mvn -q verify -Dtest=QuickFixProcessorSupportTests,QuickAssistExtensionTests -DfailIfNoTests=false
• mvn -q clean verify
• Manually verified in Eclipse 2026-06 that the proposal is hidden while signed out, appears for a Java problem marker when signed in, attaches the active Java file, prefills the diagnostic prompt, and does not auto-send.

Fixes #70

[Yutong Lyu (lytreallynb)]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

Adds a Java (JDT) Quick Assist integration that surfaces a “Suggest fix with GitHub Copilot” proposal for problem markers overlapping the caret/selection, and routes it into the existing “Open Chat” command with a prefilled (but not auto-sent) prompt. This fits the UI bundle’s existing chat command flow and keeps the initial scope limited to org.eclipse.jdt.ui.quickAssistProcessors, aligning with the linked request to have Copilot available from Eclipse’s Ctrl+1 quick assist experience.

Changes:

• Register a new JDT quick assist processor that conditionally offers a Copilot proposal when signed in.
• Collect and deduplicate overlapping problem marker messages (in source order) and build a focused prompt for chat prefill.
• Add UI test coverage for marker selection/dedup behavior and extension-point registration.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
com.microsoft.copilot.eclipse.ui/src/com/microsoft/copilot/eclipse/ui/quickfix/QuickFixProcessorSupport.java	Implements Copilot availability check, marker overlap detection, message dedup/sort, and chat command parameter creation.
com.microsoft.copilot.eclipse.ui/src/com/microsoft/copilot/eclipse/ui/quickfix/JavaCopilotQuickAssistProcessor.java	Adds the JDT IQuickAssistProcessor that produces the Copilot proposal based on caret/selection diagnostics.
com.microsoft.copilot.eclipse.ui/src/com/microsoft/copilot/eclipse/ui/quickfix/CopilotQuickFixProposal.java	Defines the completion proposal that opens Copilot Chat with a prefilled prompt and Copilot icon/label.
com.microsoft.copilot.eclipse.ui/src/com/microsoft/copilot/eclipse/ui/i18n/messages.properties	Adds user-facing strings for the quick assist proposal label and prompt header text.
com.microsoft.copilot.eclipse.ui/src/com/microsoft/copilot/eclipse/ui/i18n/Messages.java	Wires new NLS keys for quick assist strings.
com.microsoft.copilot.eclipse.ui/plugin.xml	Registers the Java quick assist processor via org.eclipse.jdt.ui.quickAssistProcessors.
com.microsoft.copilot.eclipse.ui/plugin.properties	Adds the extension name string for the quick assist processor.
com.microsoft.copilot.eclipse.ui/META-INF/MANIFEST.MF	Adds optional dependency on org.eclipse.jdt.ui for the quick assist integration.
com.microsoft.copilot.eclipse.ui.test/src/com/microsoft/copilot/eclipse/ui/quickfix/QuickFixProcessorSupportTests.java	Unit tests for overlap logic, ordering/dedup, prompt building, and chat parameter prefill behavior.
com.microsoft.copilot.eclipse.ui.test/src/com/microsoft/copilot/eclipse/ui/quickfix/QuickAssistExtensionTests.java	Verifies extension-point registration and hides proposal when Copilot is unavailable.
com.microsoft.copilot.eclipse.ui.test/META-INF/MANIFEST.MF	Adds org.eclipse.jdt.ui dependency for test runtime.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Sheng Chen (jdneo)]

Thanks, please check the ci failure. Meanwhile some questions:

1. I noticed that when the quick fix is selected, the affected range will be automatically selected, but I did not find such logic in the PR, is this controlled by upstream jdt.ui? I mean, if it's jdt.ui's behavior, we have potential regression in the future if upstream changes its behavior.

2. What if a range has multiple problem marks? What will happen?

[Yutong Lyu (lytreallynb)]

Thanks, these were good catches.

I checked JDT's JavaCorrectionAssistant implementation. It can temporarily move the caret to the nearest quick-fixable annotation with a zero-length selection, and it restores the original selection when the proposal popup closes. So yes, the behavior we observed comes from JDT UI, but it does not provide a stable, non-empty affected range that this integration should rely on.

I pushed 4877ace to make the context explicit. The Copilot proposal now returns its own selection from getSelection(). For a caret invocation, that selection covers the matched diagnostic range, or the union of the ranges when multiple matching markers overlap the caret. If the user invokes Quick Assist with an existing non-empty selection, that selection is preserved.

For multiple problem markers at the same range, we show one Copilot proposal. Its prompt contains all unique diagnostic messages, ordered by marker offset and then by message for deterministic ties. Identical messages are deduplicated. I added a regression test for multiple markers sharing the same range, including a duplicate message.

I also checked the CI failure. The Java 17 test runtime was instantiating the processor, which caused it to load a JDT UI interface compiled for Java 21. The extension registration test now verifies the registry metadata without loading the processor class. A complete clean verify passes locally with the project's Java 21 target runtime, including 10,206 core tests, 468 UI tests, and 4 UI jobs tests.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

Suppressed comments (1)

com.microsoft.copilot.eclipse.ui/src/com/microsoft/copilot/eclipse/ui/quickfix/JavaCopilotQuickAssistProcessor.java:46

• hasAssists() and getAssists() both call createProposal(context), and createProposal() does relatively expensive work (allocates a full Document from the compilation unit buffer and scans all IMarker.PROBLEM markers). If the JDT UI queries hasAssists() frequently (e.g., to update the lightbulb), this can double the work and make the editor feel sluggish.

Consider caching the last computed proposal keyed by (compilation unit + selection offset/length) so getAssists() can reuse the result from hasAssists(), or refactor so the expensive computation is only performed once per invocation context.

  @Override
  public boolean hasAssists(IInvocationContext context) throws CoreException {
    return createProposal(context) != null;
  }

  @Override
  public IJavaCompletionProposal[] getAssists(IInvocationContext context, IProblemLocation[] locations)
      throws CoreException {
    IJavaCompletionProposal proposal = createProposal(context);
    return proposal == null ? null : new IJavaCompletionProposal[] { proposal };
  }

[Sheng Chen (jdneo)]

Could hasAssists() use a lightweight availability check instead of creating the full proposal? JDT may call this method frequently when updating the quick-assist light bulb. Currently, createProposal() copies the entire compilation unit into a new Document, scans all problem markers, sorts and deduplicates them, builds the prompt, and creates a proposal. The same work is then repeated by getAssists().

Consider adding a short-circuiting helper that returns as soon as it finds an overlapping problem marker, while leaving the full proposal construction to getAssists().

[Yutong Lyu (lytreallynb)]

Thanks for pointing this out. I updated hasAssists() to use a separate availability check that stops as soon as it finds an overlapping problem marker. getAssists() still handles the full diagnostic collection and proposal construction, so that work is no longer repeated just to update the light bulb. I added tests for the new path, and clean verify passes locally.

The availability check still creates a Document up front because we also support line-only markers. I left that unchanged for now to keep this update focused. If you think it would be worthwhile, I can also make the Document creation lazy for the usual character-range marker case.