Rustify tasks by drmaniac · Pull Request #274 · zed-extensions/java

drmaniac · 2026-06-17T10:19:40Z

Key Highlights of the PR Description:

Related Issue: Connected to Issue Replace shell-based task commands with Rust proxy subcommands #252
Divergence from Proposal:
- New Crate vs. Subcommand: Introduced a separate workspace binary crate java-task-helper under Cargo.toml rather than adding a subcommand to the LSP proxy, keeping the LSP proxy focused.
- Direct Execution: The helper runs the resolved task directly ( Command::execute in command.rs) rather than outputting JSON to stdout for downstream execution.
- Native Cache Clean: Clears the JDTLS cache directly in Rust ( std::fs::remove_dir_all in main.rs) instead of delegating to shell utilities like find and rm (Job itself is now OS independent).

- Implement a new `java-task-helper` binary to handle build tool commands - Add support for Maven and Gradle build tool detection and execution - Integrate `java-task-helper` into the Zed Java extension tasks - Add automated download logic for the task helper binary - Update `justfile` with new recipes for building and installing the helper - Update `Cargo.lock` and `Cargo.toml` with new dependencies

- add test class, run all tests, and clear cache tasks to tasks.json - refactor binary download logic by moving it from proxy.rs to download.rs - update download logic to use allow_download flag and handle status updates - implement remove_all_files_except in the download flow

- update run_test_method to use file argument for module lookup - update run_test_class to use file argument for module lookup - update run_all_tests to use file argument for module lookup - refactor task_clear_cache to execute directly instead of returning TaskCommand - update main entry point to handle clear-cache subcommand

- update release-proxy.yml to build and package java-task-helper - update task_verification_test.rs to dynamically locate java-task-helper binary - remove hardcoded paths for task helper in tests

playdohface

I like this, it works on my machine™️ and already gave me ideas on how to make the tasks smarter and gives us a sane programming model for doing so.
Also, all that is missing to make this work ootb in Windows is a platform-independent way of figuring out the extension workdir in the tasks.json context - either via upstream changes in Zed or with some clever polyglot scripts.

Caveat: I can't speak to the changes in the github-workflows, it looks fine but I know too little about github workflows to say with confidence

playdohface · 2026-06-18T10:38:53Z

+    fn run_all_tests(&self, file: &str) -> TaskCommand;
+}
+
+pub fn detect_build_tool(cwd: &Path) -> (Box<dyn BuildTool>, PathBuf) {


I think this could be smarter, with similar logic like in find_closest_module - we should determine the correct build-tool and wrapper per file, walking up the tree until we find pom.xml or build.gradle and consider that the "project root". Currently, as was the case with the old shell script, the builtin tasks break if you don't open your project at the java project root which can be quite annoying

playdohface · 2026-06-18T10:41:20Z

+};
+
+const TASK_HELPER_BINARY: &str = "java-task-helper";
+const TASK_HELPER_INSTALL_PATH: &str = "proxy-bin";


nit: probably proxy-bin/ is not a great name for this folder anymore now that it contains more than just the proxy binary. I vote bin/

+1 on bin/

drmaniac · 2026-06-18T12:47:56Z

I like this, it works on my machine™️ and already gave me ideas on how to make the tasks smarter and gives us a sane programming model for doing so. Also, all that is missing to make this work ootb in Windows is a platform-independent way of figuring out the extension workdir in the tasks.json context - either via upstream changes in Zed or with some clever polyglot scripts.

Caveat: I can't speak to the changes in the github-workflows, it looks fine but I know too little about github workflows to say with confidence

Hi thanks,
Thanks especially for the polyglot keyword.
I won't get to my Windows machine until tonight. But I think this could work. I will try it out then and adjust it if necessary.

Example tasks.json:

  {
    "label": "Test class $ZED_CUSTOM_java_class_name",
    "command": ":<<\"::WINDOWS_BATCH\"\n@echo off\nset \"EXT=%LOCALAPPDATA%\\zed\\extensions\\work\\java\"\ncall \"%EXT%\\proxy-bin\\java-task-helper\" run-test-class \"%ZED_FILE%\" \"%ZED_CUSTOM_java_package_name%\" \"%ZED_CUSTOM_java_class_name%\" \"%ZED_CUSTOM_java_outer_class_name%\"\ngoto :EOF\n::WINDOWS_BATCH\nEXT=\"${XDG_DATA_HOME:-$HOME/.local/share}/zed/extensions/work/java\"; [ \"$(uname 2>/dev/null)\" = \"Darwin\" ] && EXT=\"$HOME/Library/Application Support/Zed/extensions/work/java\"; [ -n \"$LOCALAPPDATA\" ] && EXT=\"$(cygpath -u \"$LOCALAPPDATA\" 2>/dev/null || echo \"$LOCALAPPDATA\")/zed/extensions/work/java\"; \"$EXT/proxy-bin/java-task-helper\" run-test-class \"$ZED_FILE\" \"$ZED_CUSTOM_java_package_name\" \"$ZED_CUSTOM_java_class_name\" \"${ZED_CUSTOM_java_outer_class_name:-}\"",
    "use_new_terminal": false,
    "reveal": "always",
    "tags": ["java-test-class", "java-test-class-nested"]
  }

playdohface · 2026-06-18T13:27:14Z

@drmaniac yes, if we can truly make this work across platforms and shells that's a major win imo
Just some more things to keep in mind:

if we drop the shell in the task we will use the default shell, and the fauna here nowadays includes cmd.exe, PowerShell, POSIX-compatible (bash/zsh), fish and nushell. I would consider the latter two optional, though I myself use fish and would be sad if it stopped working.
the actual base directory for the extension is determined here: https://github.com/zed-industries/zed/blob/10628c3d2cafc50f78a8861d7d6882b6ecd439ce/crates/paths/src/paths.rs#L348-L351 we should make a best effort at getting it right for as broad a group of users as possible

tartarughina · 2026-06-18T13:36:04Z

Could we maybe inject the PATH to task-helper from Zed somehow? That would simplify the code in tasks.json and rely on the extension initialization accounting for all sort of install types

playdohface · 2026-06-18T14:22:06Z

@tartarughina Zed would have to provide this as a TaskVariable. It might be easier to convince the Zed team to just provide the extension-workdir or its parent as a TaskVariable to all tasks instead of doing something along the lines of zed-industries/zed#45932 and that would effectively solve our problem here, so I think it's worth a shot

That's what I believe would be required on the Zed side: zed-industries/zed#59564
It's still somewhat awkward because we'd need to append to the path in an OS and shell-agnostic way but it would be better

drmaniac added 2 commits June 17, 2026 08:06

cla-bot Bot added the cla-signed label Jun 17, 2026

drmaniac force-pushed the rustify-tasks branch 3 times, most recently from 06b2fed to c192e2a Compare June 17, 2026 11:52

build: add java-task-helper to release workflow and tests

d966d3b

- update release-proxy.yml to build and package java-task-helper - update task_verification_test.rs to dynamically locate java-task-helper binary - remove hardcoded paths for task helper in tests

drmaniac force-pushed the rustify-tasks branch from c192e2a to d966d3b Compare June 17, 2026 11:56

Update README.md

020e8e7

playdohface approved these changes Jun 18, 2026

View reviewed changes

playdohface mentioned this pull request Jun 18, 2026

Provide Zed Data Dir as a TaskVariable zed-industries/zed#59564

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rustify tasks#274

Rustify tasks#274
drmaniac wants to merge 5 commits into
zed-extensions:mainfrom
drmaniac:rustify-tasks

drmaniac commented Jun 17, 2026

Uh oh!

playdohface left a comment

Uh oh!

playdohface Jun 18, 2026

Uh oh!

playdohface Jun 18, 2026

Uh oh!

tartarughina Jun 18, 2026

Uh oh!

drmaniac commented Jun 18, 2026

Uh oh!

playdohface commented Jun 18, 2026

Uh oh!

tartarughina commented Jun 18, 2026

Uh oh!

playdohface commented Jun 18, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

drmaniac commented Jun 17, 2026

Key Highlights of the PR Description:

Uh oh!

playdohface left a comment

Choose a reason for hiding this comment

Uh oh!

playdohface Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

playdohface Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

tartarughina Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

drmaniac commented Jun 18, 2026

Uh oh!

playdohface commented Jun 18, 2026

Uh oh!

tartarughina commented Jun 18, 2026

Uh oh!

playdohface commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

playdohface commented Jun 18, 2026 •

edited

Loading