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

[diegomarquezp]

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.
  • Demo PR: chore: demo 20% of changes compute fix #31516
• 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]

fix demo for StructuredEntities.java in https://github.com/googleapis/google-api-java-client-services/pull/31516/changes#diff-7cae21c92a090112392dd43b9e2ce7d926a32c57e38b4fc9ef287627da499460

[blakeli0]

There seem to be removed methods, is that expected?

[blakeli0]

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?

[diegomarquezp]

I added a Main class to the demo PR #31516

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

[diegomarquezp]

There seem to be removed methods, is that expected?

I used the newest discovery docs for this. I'll double check whether the method was removed from the discovery.

Edit: googleapis/discovery-artifact-manager@3910620 contains the change from March 25. My local clone of discovery-artifact-manager is from beggining March 16.

commit 50c8f1b535b45207134e2d416d4c76139a78e75d (HEAD -> master, origin/master, origin/HEAD)
Author: Google APIs <noreply@google.com>
Date:   Mon Mar 16 03:40:16 2026 -0700

    chore: Automated update of Discovery documents
    
    PiperOrigin-RevId: 884340791

[blakeli0]

I see that there are a lot of type changes in the demo PR from String to java.lang.String, is it caused by this PR? If yes, can we revert them? I'm worried that this would cause a lot of unnecessary releases.

[diegomarquezp]

I see that there are a lot of type changes in the demo PR from String to java.lang.String, is it caused by this PR? If yes, can we revert them? I'm worried that this would cause a lot of unnecessary releases.

I added a special case to process string the way it was done before this PR. It's more of a hardcoded handling:

 result = self.type_map.get((json_type, None))
    if result and json_type != 'string':
      return result

When it comes to the demos, I fixed the discovery revision problem and we now only have cloudbuild (no changes) and compute.