Use MavenReference for JavaParser and update to 3.27.0 - #159
Merged
Conversation
Replace the vendored javaparser-core-3.25.4.jar with an IKVM MavenReference that resolves javaparser-core from Maven Central at build time, and update from 3.25.4 to 3.27.0 (latest). - Add IKVM.Maven.Sdk package reference to JavaToCSharp - Swap IkvmReference for MavenReference on com.github.javaparser:javaparser-core - Delete Lib/javaparser-core-3.25.4.jar from the repo - Drop the test project's duplicate IkvmReference and IKVM package reference; both now come transitively via the project reference No source changes were needed, so the 3.25.4 -> 3.27.0 upgrade is API-compatible for the surface this project uses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
paulirwin
added a commit
that referenced
this pull request
Aug 16, 2026
Fixes the intermittent test failures noted in #159. `JavaToCSharp` was not safe to call concurrently. This affects real consumers converting files in parallel, and it was also causing flaky CI: roughly 1 run in 10 failed, in a *different* test class each time. ## The bug `TypeNameParser` was a `static` class holding its **entire recursive-descent parse state** in static fields — including a shared `StringBuilder`: ```csharp private static (string, TokenType)[]? _tokens; private static (string text, TokenType type) _token; private static int _currentIndex; private static readonly StringBuilder _sb = new(); ``` `ConvertType` is on the hot path of essentially every conversion, and xUnit runs test classes in parallel. Two conversions interleaving `_sb.Clear()` / `_sb.Append()` splice each other's output — the symptom that led me here was generated code containing: ```csharp public static voidvoid Main(string[] args) ``` The return type emitted twice. Concurrent mutation of the shared token array and index can also throw `IndexOutOfRangeException` outright, which is what the new test hits first against the old code. ## The fix - **`TypeNameParser` is now an instance class**, constructed fresh per `ParseTypeName` call, so no parse state is shared. The public entry point is unchanged — this is not a breaking change. - **`TypeHelper._typeNameConversions` is now a `ConcurrentDictionary`.** It's mutated during conversion by `ClassOrInterfaceDeclarationVisitor` (registering interface renames when `StartInterfaceNamesWithI` is set) while other threads read it in `ConvertType` — undefined behavior for `Dictionary<,>`. - Dropped two now-dead defensive checks: `_tokens` is always assigned in the constructor, and `_translate?.Invoke(...)` was silently appending an empty string on null rather than failing. ## Testing New `ConcurrencyTests` covers parallel `ConvertType` calls and parallel end-to-end conversions. I verified these are genuine regression tests: **both fail reliably against the old code** (stashed the fix and confirmed) and pass with it. Full suite run **15 consecutive times: 286/286 passing every time**. On `master` the same loop reproduces a failure within ~10 runs. ## Note on scope `TypeHelper._typeNameConversions` being process-global mutable state is still a design smell — per-file class renames leak between conversions, so converting two files with `StartInterfaceNamesWithI` can bleed one file's renames into the other. The proper fix is moving it onto `ConversionContext`, but `ConvertType` has ~60 call sites and is public API used directly by tests, so that's a larger breaking change. This PR makes it *safe* without changing the API; happy to do the deeper refactor separately if you want it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Fixes #117.
Replaces the vendored
javaparser-core-3.25.4.jarwith an IKVMMavenReferencethat resolves javaparser-core from Maven Central at build time, and updates 3.25.4 → 3.27.0 (latest).Changes
IKVM.Maven.Sdk1.12.0 toJavaToCSharp— this is the package that providesMavenReference; theIKVMpackage alone doesn't.IkvmReferenceforMavenReferenceoncom.github.javaparser:javaparser-core.Lib/javaparser-core-3.25.4.jar(theLib/directory is now gone).IkvmReferenceand itsIKVMpackage reference — both were only there to build the jar locally, and now come transitively via the project reference.Version note
3.27.0 is the latest, a few releases past the 3.26.1 suggested in the issue. It required no source changes — clean build, 0 warnings — so the upgrade is API-compatible for the surface this project uses. Verified the generated
com.github.javaparser.core.dllactually carries 3.27.0 rather than trusting the restore.javaparser-core-serializationfrom the issue's snippet is intentionally omitted — nothing in the codebase uses it.Testing
bin/objwiped), 0 warnings, 0 errors.Unrelated pre-existing issue found while verifying
While testing I hit generated output containing
public static voidvoid Main(return type emitted twice). That looked like a 3.27.0 regression, so I checked: it reproduces on unmodifiedmasterat 3.25.4 (~1 run in 10) and is unrelated to this PR.The cause is
TypeNameParserholding its entire recursive-descent parse state — including a sharedStringBuilder— instaticfields, so parallel conversions splice each other's output. This means the library is not safe to call concurrently. Being fixed separately.🤖 Generated with Claude Code