Support Records as Beans #459
Conversation
📝 WalkthroughWalkthroughThe pull request introduces comprehensive support for Java records in the Joda-Beans library. The changes include adding new classes like Changes
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/main/java/org/joda/beans/impl/RecordBean.java (1)
52-52: Consider clarifying the interface's placement under theimplpackage.
Although this interface is declaredpublic, placing it in animplpackage might cause confusion for consumers regarding whether it is official public API or an internal implementation detail.src/main/java/org/joda/beans/MetaBeans.java (1)
100-112: Race condition avoided with synchronisation.
The synchronised block correctly avoids duplicate registration for the same class. The subsequent check forcls.isRecord()within it is clear and ensures concurrency correctness.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
src/main/java/org/joda/beans/JodaBeanUtils.java(2 hunks)src/main/java/org/joda/beans/MetaBeans.java(3 hunks)src/main/java/org/joda/beans/impl/RecordBean.java(1 hunks)src/main/java/org/joda/beans/impl/RecordBeanBuilder.java(1 hunks)src/main/java/org/joda/beans/impl/RecordMetaBean.java(1 hunks)src/main/java/org/joda/beans/impl/RecordMetaProperty.java(1 hunks)src/main/java/org/joda/beans/impl/light/LightBeanBuilder.java(1 hunks)src/main/java/org/joda/beans/impl/light/LightMetaProperty.java(1 hunks)src/test/java/org/joda/beans/TestRecordBean.java(1 hunks)src/test/java/org/joda/beans/sample/RecordStrIntPair.java(1 hunks)
🧰 Additional context used
📓 Path-based instructions (10)
src/test/java/org/joda/beans/sample/RecordStrIntPair.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/test/java/**/*.java: For test code, focus on:
- Correctness of test assertions
- Test coverage of edge cases
- Clear test naming and documentation
- Encourage test methods to be package-scoped where possible
- Be more lenient with code style and minor optimisations
src/main/java/org/joda/beans/impl/RecordMetaBean.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/main/java/org/joda/beans/impl/light/LightMetaProperty.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/main/java/org/joda/beans/impl/light/LightBeanBuilder.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/test/java/org/joda/beans/TestRecordBean.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/test/java/**/*.java: For test code, focus on:
- Correctness of test assertions
- Test coverage of edge cases
- Clear test naming and documentation
- Encourage test methods to be package-scoped where possible
- Be more lenient with code style and minor optimisations
src/main/java/org/joda/beans/impl/RecordBean.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/main/java/org/joda/beans/impl/RecordBeanBuilder.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/main/java/org/joda/beans/impl/RecordMetaProperty.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/main/java/org/joda/beans/MetaBeans.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/main/java/org/joda/beans/JodaBeanUtils.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
🔇 Additional comments (13)
src/main/java/org/joda/beans/impl/RecordBean.java (2)
65-72: Ensure reflective registration is safe in multi-threaded environments.
Multiple threads might concurrently try to register the same record meta-bean. Consider whether this method—together with any usage in the MetaBeans class—requires additional synchronisation to avoid redundant or conflicting registrations.
88-91: Default method usage is appropriate.
Providing a default metaBean() is a neat way to simplify record-based beans, ensuring they do not need boilerplate code. The approach here aligns with the library’s design.
src/main/java/org/joda/beans/impl/RecordMetaBean.java (3)
42-69: Reflection-based construction is well-structured but verify security constraints.
Using MethodHandles.Lookup and reflection is flexible. However, confirm that only trusted code is permitted to register record beans. If untrusted code can register malicious records, reflection-based handle usage may pose a security risk.
71-79: Error handling is suitable for inaccessible record components.
An IllegalArgumentException is thrown for inaccessible getters. This is consistent with the rest of the library’s approach for invalid bean definitions.
81-99: Constructor handle creation looks robust.
The code uses asSpreader and sets the return type to ImmutableBean, ensuring a consistent signature for building record instances. This mechanism appears coherent with the library’s reflection strategy.
src/test/java/org/joda/beans/sample/RecordStrIntPair.java (1)
26-28: Test record usage is concise and illustrative.
The record-based bean is straightforward, effectively demonstrating how to implement RecordBean. It aids test coverage for record integration.
src/main/java/org/joda/beans/impl/RecordBeanBuilder.java (1)
27-73: Builder implementation is clear and consistent with immutable patterns.
The RecordBeanBuilder sets property values in an array before constructing the immutable bean. This approach matches the existing Joda-Beans style.
src/main/java/org/joda/beans/impl/light/LightBeanBuilder.java (1)
42-42: Constructor Parameter Documentation Check
The new data parameter is clearly documented and aids in storing property values. This change looks logically consistent with the builder approach in this package.
src/main/java/org/joda/beans/impl/RecordMetaProperty.java (1)
1-133: Comprehensive New Class Implementation
This class appears to provide well-structured, immutable record meta-properties, with appropriate handling of getter methods and a clear exception when writing is attempted. The code aligns with record immutability in Java 21.
src/test/java/org/joda/beans/TestRecordBean.java (1)
1-149: Overall Test Coverage
The new tests thoroughly validate the functionality of record beans, including builder usage, exception handling, and JSON serialisation. They adhere to best practices, verifying both public and private record handling.
src/main/java/org/joda/beans/impl/light/LightMetaProperty.java (1)
129-130: Variable Name Correction
Renaming the local variable to methodType improves clarity. The updated invocation in lookup.findVirtual now matches the naming convention consistently throughout the method.
src/main/java/org/joda/beans/JodaBeanUtils.java (2)
408-408: Ensure immutability or document the risk of subsequent modification.
Replacing Map.copyOf(map) with Collections.unmodifiableMap(map) creates a read-only view, which can still reflect changes to the underlying LinkedHashMap. If immutability is essential, ensure map is never mutated after this point, or switch to a fully immutable map creation approach.
776-776: Confirm that shared references are not mutated elsewhere.
Similar to line 408, returning Collections.unmodifiableMap(resolved) prevents direct modifications on the returned map but does not guarantee full immutability if resolved is changed later. Verify that no further changes occur to resolved downstream to avoid unexpected behaviour.
* Add support for JLS records as beans * Avoid `Map.copyOf` as iteration is random
jodastephen
force-pushed
the
record-bean
branch
from
03c75c0 to
1d6d12e
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (6)
src/main/java/org/joda/beans/impl/RecordMetaProperty.java (2)
36-36: Consider verifying the completeness of JavaDoc comments.
The class-level JavaDoc clearly states its purpose, but you may wish to add further usage examples or note any limitations (for instance, that setters are unsupported). This can help future maintainers understand the context and constraints.
103-105: Revisit the exception message for clarity.
When an unknown property is encountered, it currently raises "Unknown property: ...". Consider adding additional contextual cues, for example referencing the bean class.src/main/java/org/joda/beans/impl/RecordMetaBean.java (1)
65-67: Add more detail to the exception message.
When the record constructor is missing, it might be helpful to mention the parameter types that were attempted. This could speed up debugging for record-based beans.src/test/java/org/joda/beans/TestRecordBean.java (1)
90-93: Ensure JSON-based tests cover all record properties.
These tests confirm correct serialisation/deserialisation for two basic properties. If more complex properties or derived properties are introduced in future, ensure coverage of edge cases such as null values.src/main/java/org/joda/beans/MetaBeans.java (1)
100-112: LGTM! Well-implemented synchronization and record handling.The synchronization block effectively prevents race conditions, and the record handling logic is properly implemented with appropriate type safety.
Consider extracting the record handling logic into a private method for better readability:
- if (cls.isRecord() && ImmutableBean.class.isAssignableFrom(cls)) { - @SuppressWarnings({"rawtypes", "unchecked"}) - var metaBean = RecordBean.register((Class) cls, MethodHandles.lookup()); - return metaBean; - } + var metaBean = handleRecordClass(cls); + if (metaBean != null) { + return metaBean; + } + private static MetaBean handleRecordClass(Class<?> cls) { + if (cls.isRecord() && ImmutableBean.class.isAssignableFrom(cls)) { + @SuppressWarnings({"rawtypes", "unchecked"}) + var metaBean = RecordBean.register((Class) cls, MethodHandles.lookup()); + return metaBean; + } + return null; + }src/changes/changes.xml (1)
Line range hint
1-1: Walkthrough of Public API Changes
- New public interface
RecordBeanthat can be implemented by records- Modified behaviour in
MetaBeans.lookup(Class<?>)to support record classes- New static method
RecordBean.register(Class, MethodHandles.Lookup)for registering record meta-beansThese changes will affect end users who:
- Want to implement beans using Java records
- Use the meta-bean lookup functionality with record classes
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
src/changes/changes.xml(1 hunks)src/main/java/org/joda/beans/JodaBeanUtils.java(2 hunks)src/main/java/org/joda/beans/MetaBeans.java(3 hunks)src/main/java/org/joda/beans/impl/RecordBean.java(1 hunks)src/main/java/org/joda/beans/impl/RecordBeanBuilder.java(1 hunks)src/main/java/org/joda/beans/impl/RecordMetaBean.java(1 hunks)src/main/java/org/joda/beans/impl/RecordMetaProperty.java(1 hunks)src/main/java/org/joda/beans/impl/light/LightBeanBuilder.java(1 hunks)src/main/java/org/joda/beans/impl/light/LightMetaProperty.java(1 hunks)src/test/java/org/joda/beans/TestRecordBean.java(1 hunks)src/test/java/org/joda/beans/sample/RecordStrIntPair.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- src/test/java/org/joda/beans/sample/RecordStrIntPair.java
- src/main/java/org/joda/beans/impl/light/LightBeanBuilder.java
- src/main/java/org/joda/beans/impl/RecordBeanBuilder.java
- src/main/java/org/joda/beans/impl/light/LightMetaProperty.java
- src/main/java/org/joda/beans/JodaBeanUtils.java
🧰 Additional context used
📓 Path-based instructions (5)
src/main/java/org/joda/beans/impl/RecordBean.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/main/java/org/joda/beans/impl/RecordMetaProperty.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/main/java/org/joda/beans/impl/RecordMetaBean.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
src/test/java/org/joda/beans/TestRecordBean.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/test/java/**/*.java: For test code, focus on:
- Correctness of test assertions
- Test coverage of edge cases
- Clear test naming and documentation
- Encourage test methods to be package-scoped where possible
- Be more lenient with code style and minor optimisations
src/main/java/org/joda/beans/MetaBeans.java (2)
Pattern **/*.java: - Review code using Java 21 standards, taking into account the rules defined by src/main/checkstyle/checkstyle.xml.
- Validate that code indentation uses spaces, not tabs, with an indent of multiple of 4.
- Validate that immutable local variables are not annotated with
finalunless the variable is required for use in an inner class. - Favour use of
varkeyword for type declarations.varmay also be used when the value is a castnull. - Use a coding standard where multi-line expressions have operators and tenary separators at the end of line.
- Propose changes that only use the Java 21 API, not the API of Guava.
- The pattern matching
instanceofexpression safely handlesnull, returningfalse.
Pattern **/main/java/**/*.java: - This project is mature and must provide a stable backwards-compatible public Java API.
- In the 'Walkthrough' section, you must always provide a list of up to 25 changes to the public Java API that will affect end users.
If there are no changes, you must explicitly state that there are no changes to the public Java API in this PR.
The public Java API is defined as public and protected methods on public classes, plus the filemodule-info.java.
Provide the list by deeply analysing code flow, which incudes analysing code flow through private methods and calls to Guava and Java 21.
Changes to be reported on include:- New or removed methods in the public Java API
- Changes to method return types or parameter types in the public Java API
- Changes to method behaviour in the public Java API that might affect consumers
- This project uses
System.out.printlninstead of logging - This project tends to prefer
forloops to streams for performance reasons, however either form is acceptable.
Do not make suggestions to change between streams and for loops or vice versa.
🔇 Additional comments (7)
src/main/java/org/joda/beans/impl/RecordBean.java (1)
52-52: Ensure that the interface remains forward-compatible.
As this interface is public, any changes in future releases, such as adding methods, could break existing implementations. Keep the surface area minimal or add default methods as necessary.
src/main/java/org/joda/beans/impl/RecordMetaBean.java (1)
42-42: Confirm internal visibility of this class.
Since this class is package-private, it is effectively internal API. Ensure this approach is intentional, as external usage could be blocked if clients rely on reflection.
src/test/java/org/joda/beans/TestRecordBean.java (1)
35-39: Good practice employing static initialisation for private record registration.
Using the static { RecordBean.register(...) } approach ensures that the meta-bean is registered once in a controlled manner. This is a tidy pattern for non-public records in tests.
src/main/java/org/joda/beans/MetaBeans.java (3)
18-18: LGTM! Required imports added for record support.
The new imports for MethodHandles and RecordBean are necessary for implementing the record support functionality.
Also applies to: 24-24
37-37: LGTM! Well-documented field choices.
The fields use appropriate concurrent collections, and the comments clearly explain why ClassValue is not used in each case.
Also applies to: 43-43
Line range hint 113-134: LGTM! Comprehensive provider annotation handling.
The provider annotation handling is well-structured with proper error handling and clear exception messages.
src/changes/changes.xml (1)
17-20: LGTM! Clear documentation of record support feature.
The changes are well-documented, clearly stating the addition of record support and the new RecordBean interface.
Map.copyOfas iteration is randomSummary by CodeRabbit
Release Notes
New Features
Improvements
Bug Fixes
Testing
The update provides enhanced support for Java records within the Joda-Beans library, improving type safety and bean management.