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: PR #new/demo-20pct-generation
• 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?