[Java SDK] Infer Beam logical types for JSR-310 and UUID fields

[sachinnn99]

Summary

• StaticSchemaInference.fieldFromType() now maps java.time.LocalDate, LocalTime, LocalDateTime, java.time.Instant, and UUID to their corresponding Beam logical types (SqlTypes.DATE, TIME, DATETIME, NanosInstant, SqlTypes.UUID)
• ByteBuddyUtils gains convertJavaTimeLogicalType() in both getter and setter codegen paths, calling LogicalType.toBaseType() / toInputType() so POJO/Bean ↔ Row round-trips work correctly
• Comprehensive tests covering schema inference, toRow, fromRow, round-trip, nullable fields, mixed schemas, and backward compatibility with Joda ReadableInstant

Fixes #37524

Test plan

• POJOUtilsTest — schema inference for JSR-310 types + Joda regression test
• JavaFieldSchemaTest — schema, toRow, fromRow, round-trip, nullable toRow/fromRow
• JavaBeanSchemaTest — schema + round-trip
• JavaBeanUtilsTest — schema inference for beans
• ConvertTest — Convert.fromRows() with logical-type DateTime (reproducer for [Bug]: JavaFieldSchema does not support for Beam Logical Types #37524) + mixed logical/primitive schema

R: @ahmedabu98

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the Java SDK's schema inference capabilities by introducing native support for modern Java date/time types (JSR-310) and UUIDs as Beam logical types. This change streamlines the process of converting Java objects (POJOs and JavaBeans) containing these types into Beam Rows and vice-versa, improving data interoperability and addressing a known issue related to schema assignability with external systems like Iceberg.

Highlights

• JSR-310 and UUID Logical Type Inference: The StaticSchemaInference.fieldFromType() method now correctly maps java.time.LocalDate, LocalTime, LocalDateTime, java.time.Instant, and UUID to their corresponding Beam logical types (SqlTypes.DATE, TIME, DATETIME, NanosInstant, SqlTypes.UUID).
• ByteBuddyUtils Enhancements for JSR-310/UUID Conversions: ByteBuddyUtils has been updated to include convertJavaTimeLogicalType() in both getter and setter codegen paths. This ensures that POJO/Bean to Row and Row to POJO/Bean round-trips work correctly for these new logical types by calling LogicalType.toBaseType() and toInputType() respectively.
• Comprehensive Test Coverage: Extensive tests have been added to cover schema inference, toRow and fromRow conversions, round-trip functionality, nullable fields, mixed schemas, and backward compatibility with Joda ReadableInstant to prevent regressions.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[sachinnn99]

/gemini review

[gemini-code-assist]

Code Review

This pull request implements schema inference and ByteBuddy-based code generation support for JSR-310 date/time types (LocalDate, LocalTime, LocalDateTime, java.time.Instant) and UUIDs. It introduces static LogicalType instances for these types and updates the conversion logic to handle them during row-to-object and object-to-row transformations. A critical issue was identified where the new abstract method 'convertJavaTimeLogicalType' lacks implementations in 'SetterTypeConversion' and 'CreatorParameterTypeConversion', which will result in compilation errors.

[gemini-code-assist]

The addition of the abstract method convertJavaTimeLogicalType to the TypeConversion class requires an implementation in all of its subclasses to avoid compilation errors. While you have provided implementations for GetterTypeConversion, GetterPropertyConversion, and SetterPropertyConversion, you appear to have missed SetterTypeConversion and CreatorParameterTypeConversion. Both of these subclasses also extend TypeConversion and must implement this new method.

For SetterTypeConversion and CreatorParameterTypeConversion, returning Object.class (similar to GetterTypeConversion) should be appropriate as the generated code handles the specific casting in the property conversion path.

[github-actions]

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

[ahmedabu98]

Overall LGTM, just left one comment

Would like @kennknowles to also skim through to check for anything I missed

[ahmedabu98]

Wondering if we can expand the naming of this logic to include other LogicalTypes in the future? Instead of restricting it to just Time types. We already include UUID, might as well open it up to other LogicalTypes?

[ahmedabu98]

Hey @sachinnn99, you mentioned renaming the new methods from time-type specific to use generic LogicalType naming. Wondering if you're still planning to or if you changed your mind

[sachinnn99]

Done — renamed to convertLogicalType / inferredLogicalTypeFor / loadLogicalType in the latest push.

[sachinnn99]

Thanks for the review @ahmedabu98! Two follow-ups:

Naming: Agreed. Planning to rename the helper to inferredLogicalTypeFor so additional LogicalType inferences (Decimal/URI/etc.) extend that one helper rather than spawning per-type methods.

CI — Avro regression: The "failure" status on CI hides a real issue I want to flag before you merge: AvroSchemaTest.testSpecificRecordToRow and testRowToSpecificRecord fail with ClassCastException/AssertionError. Root cause is that the new javaTimeLogicalTypeFor(...) check in TypeConversion.convert() is a concrete-class whitelist placed ahead of convertDefault, while every other branch in that method is structural (isSubtypeOf, isArray, isPrimitive, isEnum). Avro's convertDefault overrides for java.time.Instant / java.time.LocalDate (which bridge to Joda Instant for Beam's DATETIME Row representation) are now dead code — they never run.

Two ways to fix:

1. Override convertJavaTimeLogicalType in the three Avro subclasses to apply the existing Joda conversion. Follows the convertDateTime precedent.
2. Fold the JSR-310/UUID handling into convertDefault() of the three base subclasses, drop the new abstract method + dispatch branch. Top-level dispatch stays structural; Avro's existing convertDefault override handles this naturally (with super.convertDefault fallback for LocalTime/LocalDateTime/UUID which Avro doesn't special-case). Zero changes to AvroUtils.java.

I'm leaning toward (2) since convertDefault is already where Avro holds its concrete-class checks, but happy to go with (1) if you prefer sticking closer to the convertDateTime precedent. Which direction do you prefer?

[ahmedabu98]

Thanks for the helpful breakdown @sachinnn99!

I think either way works really. I personally prefer having a concrete convertLogicalType method for LogicalType handling, makes it easier to follow where things are. If we go with (1) we can also just remove the existing Java time handling in Avro's convertDefault.

But there's no wrong solution here, I'll leave it up to your judgement as the PR author.

[sachinnn99]

@ahmedabu98 Went with approach (1) — added convertJavaTimeLogicalType overrides in the three Avro subclasses that preserve the existing Joda bridging for java.time.Instant and java.time.LocalDate. Removed the now-dead branches from convertDefault. Rebased on master and pushed.

[codecov]

Codecov Report

❌ Patch coverage is 94.50549% with 5 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (master@281270c). Learn more about missing BASE report.
⚠️ Report is 41 commits behind head on master.

Files with missing lines	Patch %	Lines
...m/sdk/extensions/avro/schemas/utils/AvroUtils.java	86.95%	3 Missing ⚠️
.../apache/beam/sdk/schemas/utils/ByteBuddyUtils.java	96.55%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #38194   +/-   ##
=========================================
  Coverage          ?   57.65%           
  Complexity        ?    13364           
=========================================
  Files             ?     2604           
  Lines             ?   266801           
  Branches          ?    11014           
=========================================
  Hits              ?   153820           
  Misses            ?   107184           
  Partials          ?     5797           

Flag	Coverage Δ
java	63.20% <94.50%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Assigning reviewers:

R: @chamikaramj for label java.

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

[kennknowles]

LGTM. Thanks for adding test coverage!

[sachinnn99]

@chamikaramj This has approvals from @ahmedabu98 and @kennknowles — could you merge when you get a chance? Happy to address anything if needed.

[github-actions]

Reminder, please take a look at this pr: @chamikaramj

[github-actions]

Assigning new set of reviewers because Pr has gone too long without review. If you would like to opt out of this review, comment assign to next reviewer:

R: @ahmedabu98 for label java.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

[damccorm]

@kennknowles @ahmedabu98 is this ready to merge?