Summary

This pull request addresses non-deterministic behavior in the processor module, such as Java8CustomPatternDateTimeFormatterGeneratedTest, which fail intermittently due to non-deterministic field ordering in the generated code. This behavior was identified using the NonDex tool.

The Root Cause

The core issue is that the code generation process does not guarantee a stable order for helper fields (e.g., DateTimeFormatter instances). This is because the processor iterates over a list of methods, which are stored in HashSet initially, in an order that can vary between builds. As a result, the generated mapper implementation can have its fields declared in different sequences, causing tests that perform a direct string comparison against a "golden file" to fail.

The Implemented Solution

This PR makes the test suite more robust by changing the assertion logic rather than the code generation logic itself.

The JavaFileAssert utility has been modified to handle non-deterministic field order. The new assertion logic works as follows:

1. Parses both the actual and expected Java source files.
2. Separates the member fields from the rest of the class implementation.
3. Sorts both lists of fields alphabetically.
4. Compares the sorted lists of fields for equality.
5. Compares the remaining parts of the class implementation for equality.

This approach ensures that the test correctly verifies the generated code's content and structure while being resilient to changes in field ordering.

Alternative Considered

An alternative approach would be to make the code generation itself deterministic by sorting the list of methods in MethodRetrievalProcessor before processing. This PR takes the approach of hardening the test assertion as it is a more localized change that directly addresses the test's flakiness without modifying the core processor's behavior.

Issue related: #3940