Skip to content

fix(generator): fall back to java.lang.Object for unknown types.#31517

Open
diegomarquezp wants to merge 2 commits intomainfrom
fix-compute-generation
Open

fix(generator): fall back to java.lang.Object for unknown types.#31517
diegomarquezp wants to merge 2 commits intomainfrom
fix-compute-generation

Conversation

@diegomarquezp
Copy link
Copy Markdown
Contributor

@diegomarquezp diegomarquezp commented Apr 15, 2026

Fixes #31266

Background

When compiling specific alpha/beta generated model endpoints (e.g., StructuredEntries in google-api-services-compute), the Java compiler crashes on:

[ERROR] .../com/google/api/services/compute/model/StructuredEntries.java:[38,25] error: cannot find symbol
[ERROR]   symbol:   class Any
[ERROR]   location: package java.util

This happens because the property "entries" uses a schema format that the current Java generator does not explicitly handle, defined in the upstream discovery document here:
discoveries/compute.alpha.json

"additionalProperties": {
  "format": "google.protobuf.Value",
  "type": "any"
}

Since ('any', 'google.protobuf.Value') has no dedicated mapping, the code generation fell through to the default class transformation logic.

Faulty snippet in java_generator.py:

    # No mapping found for (json_type, json_format)
    result = self.type_map.get((json_type, json_format))
    if result:
      return result

    # (Missing fallback handling for `json_format = None`)

    # Erroneously transforms "any" into "Any" class reference
    return (utilities.CamelCase(json_type), None, None)

This resulted in the pseudo-class reference Any.

Changes Proposed

  • Restored the standard unformatted fallback mechanism in JavaLanguageModel._GetTypeInfo so that any unmapped (type, format) signature automatically strips the format requirement and probes the base (type, None) type list instead.
  • This safely redirects opaque formats (like google.protobuf.Value) to standard mappings (like java.lang.Object), avoiding unintended transitive dependencies on external protobuf-java libraries.

Testing & Impact Verification

  • Sample Check: Regenerated a random 20% sample (~46 packages) of all v1/2.0.0 libraries to check for unintended regressions.
  • Observations: Zero structural schema modifications or base type shifts were observed among existing stable models. The change exclusively activates for custom format string combinations that were previously generating invalid mock class types.

@diegomarquezp
Copy link
Copy Markdown
Contributor Author

@diegomarquezp diegomarquezp marked this pull request as ready for review April 15, 2026 18:39
@diegomarquezp diegomarquezp requested review from a team and yoshi-approver as code owners April 15, 2026 18:39
@blakeli0
Copy link
Copy Markdown
Contributor

There seem to be removed methods, is that expected?

# return result
#
# raise ValueError('Unknown type: %s format: %s' % (json_type, json_format))
# Fallback to the unformatted base type if exact format mapping is not found.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that the generated code changed from

  private java.util.Map<String, Any> entries;

to

  private java.util.Map<String, java.lang.Object> entries;

Is it possible to test it in a real client?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a Main class to the demo PR #31516

The description now explains that we could compile and fetch a StructuredEntities object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Investigate reason for compute not being released

2 participants