In general, this sort of thing needs to be submitted as small, isolated PRs that are focused on exactly one thing. Code review time is extremely limited. I'm not sure if a non-committer can approve PRs or not, but if so it would be more helpful to contribute as a code reviewer than a coder.
Gradle or Maven is a non-starter for now. We can consider that only after the build actually works, tests run, and releases are possible. Lambdas are usually a bad idea. There might be isolated cases where they're clearer than a simple loop, but that's rare. In any case, I'm not sure we currently require Java 8. That might be a blocker. I'd have to check. But whether we do or don't, please don't churn the code just to introduce the new hotness when the old hotness works perfectly well. Microbenchmarks rarely identify anything with a macro effect, but as long as an optimization doesn't make code more opaque or convoluted, I'll consider it. However, production benchmarks are much more convincing. try-with-resources is useful where it fits, especially on code paths where resources might not be properly closed already. JUnit 5 is a maybe, but it doesn't add a lot of benefit, and I'd prefer not to burn time on it. On the other hand, converting non-JUnit tests to JUnit is very useful, and needs to be completed before we consider migrating to a new JUnit version. Some of the Xerces codebase is very old and might predate JUnit 1.0. We have a lot of "tests" that do not actually run. There are probably still a couple that are failing but don't break the build. I have over a dozen PRs to fix this that have been open for months without any reviews. TBH there are a lot of real issues and bugs we should address. We get periodic offers to do work like this that churns code without offering user value. On Tue, Sep 1, 2026 at 11:49 AM Lars Michele <[email protected]> wrote: > > Hi everyone, > I have recently been working on modernizing and profiling some of the > core components of Xerces-J. I have pushed these experimental changes to > my personal fork and would love to get your feedback on contributing > some or all of this work upstream. > Here is a brief summary of the changes I have made on my fork: > > • Build & Test Modernization: Migrated the legacy Ant build to a > standard Gradle multi-module structure. > • JUnit 5 Migration: Converted the conformance test suites (JAXP, DOM, > XInclude, Schema, etc.) to pure JUnit 5 Jupiter. > • Java 8 Adoption: Replaced older iteration patterns and resource > handling with Java 8 features (lambdas, try-with-resources) across > various modules. > • New JMH Benchmark Suite: Created a dedicated xerces-benchmarks > submodule to systematically profile SAX, StAX, and DOM workloads. > • Performance Enhancements: Derived from the benchmarks, I implemented > several micro-optimizations (e.g., in XMLEntityScanner, SymbolTable > resizing, and string buffer boundaries). > > You can review the full history of these changes in the main branch of > my fork here: https://github.com/lyca/xerces-j > Since this is a rather substantial set of changes (around 80 commits), I > wanted to reach out to the list before opening any massive Pull > Requests. What would be the preferred process for you? > I would be more than happy to slice this into smaller, isolated JIRA > tickets and open sequential PRs (e.g., starting exclusively with the > JUnit 5 modernization or the JMH scaffolding, and leaving the core > performance adjustments for later). > > (Note for transparency in accordance with the ASF generative tooling > guidance: I used the help of my AI assistant, Gemini / Antigravity, to > actively collaborate on this modernization effort. The AI helped me > significantly with executing the structural refactorings, generating the > boilerplate for the new benchmark suite, and writing the commits. I > have, of course, thoroughly reviewed and take full responsibility for > all changes). > > Please let me know how you prefer to handle such structural > contributions and where you think I should start! > Best regards, > Lars Michele > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
