Skip to content

Java FFI: Fix build collision when many builds/rules compile the same Java class - #2861

Merged
privat merged 2 commits into
nitlang:masterfrom
xymus:fix-java-concurrent
Aug 19, 2026
Merged

Java FFI: Fix build collision when many builds/rules compile the same Java class#2861
privat merged 2 commits into
nitlang:masterfrom
xymus:fix-java-concurrent

Conversation

@xymus

@xymusxymus commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

When building Java FFI clients with any concurrency, even with only make -j n, different rules could target compiling the same java file to class file in parallel. It causes failures when one tries to read a class while it's being written and still only a partial file.

For collisions between two builds sharing a build folder, we now compile the java file to a class file in a temporary directory per main target. This folder sits under the compile dir and gets cleared with it. Once the class file is compiled, we move it over to the normal build folder. The atomic move avoids clients reading partially generated files.

For collisions inside the same build, we pass -implicit:none so only the target of the command is being built, and none of its dependencies. This still allows us to build the java files in parallel but avoids the repeated writes.

Returning lines allows the caller and printer to insert the tabs
automatically at the beginning of each line.
Signed-off-by: Alexis Laferrière <alexis.laf@xymus.net>
…ava class
When building Java FFI clients with any concurrency, even with only
`make -j n`, different rules could target the same java file to class file in
parallel. It causes failures when one tries to read a class while it's
being written and still only a partial file.
For collisions between two builds sharing a build folder, we now compile
the java file to a class file in a temporary directory per main target.
This folder sits under the compile dir and gets cleared with it.
Once the class file is compiled, we move it over to the normal build folder.
The atomic move avoids clients reading partially generated files.
For collisions inside the same build, we pass `-implicit:none ` so only
the target of the command is being built, and none of its dependencies.
This still allows us to build the java files in parallel but avoids the
repeated writes.
Signed-off-by: Alexis Laferrière <alexis.laf@xymus.net>
@github-actions

github-actionsBot commented Aug 14, 2026

Copy link
Copy Markdown

Test Results

67 files 337 suites 16m 11s ⏱️
14 236 tests 13 689 ✅ 547 💤 0 ❌
14 622 runs 14 060 ✅ 562 💤 0 ❌

Results for commit 233cd6c.

♻️ This comment has been updated with latest results.

@xymus
xymus requested a review from privatAugust 17, 2026 19:01

@privatprivat left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@privat
privat merged commit 974e4ea into nitlang:masterAug 19, 2026
60 of 61 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@xymus@privat