apache / apache/dubbo

[Bug] When running a Dubbo 3.3.6 application on JDK 25, application startup fails with `NoClassDefFoundError: com/google/gson/JsonSyntaxException`.

Open
#16,295 6 comments 0 reactions 0 assignees View on GitHub
help wanted
Dominant language
Java
Stars
41.6k
Forks
26.4k
Avg merge
15h 13m
Merged PRs (30d)
4

Description

### Pre-check

- [x] I am sure that all the content I provide is in English.

### Search before asking

- [x] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar issues.

### Apache Dubbo Component

Java SDK (apache/dubbo)

### Dubbo Version

When running a Dubbo 3.3.6 application on JDK 25, application startup fails with `NoClassDefFoundError: com/google/gson/JsonSyntaxException`.

The application does not depend on Gson and does not intend to use Gson as Dubbo's JSON implementation. Dubbo's default JSON implementation should be `fastjson2`, and the same application starts normally on JDK 21.

### Steps to reproduce this issue

```text
Caused by: java.lang.NoClassDefFoundError: com/google/gson/JsonSyntaxException
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:2985)
at java.base/java.lang.Class.getConstructor0(Class.java:3180)
at java.base/java.lang.Class.getConstructor(Class.java:2199)
at java.base/java.util.ServiceLoader.getConstructor(ServiceLoader.java:623)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1111)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1142)
at org.apache.dubbo.common.utils.JsonUtils.loadExtensions(JsonUtils.java:81)
at org.apache.dubbo.common.utils.JsonUtils.createJsonUtil(JsonUtils.java:52)
at org.apache.dubbo.common.utils.JsonUtils.getJson(JsonUtils.java:40)
at org.apache.dubbo.common.utils.JsonUtils.toJavaObject(JsonUtils.java:106)
at org.apache.dubbo.registry.client.metadata.store.MetaCacheManager.toValueType(MetaCacheManager.java:73)
```
### Expected behavior

Dubbo should not fail startup because the optional Gson dependency is absent, especially when Gson is not selected as the JSON implementation.

If fastjson2 is the default/preferred JSON implementation, Dubbo should be able to select it without forcing ServiceLoader to instantiate or inspect the Gson implementation class.

### Actual behavior

On JDK 25, ServiceLoader appears to inspect the Gson JSON implementation during Dubbo JSON SPI loading. Since Gson is not on the classpath, this causes startup failure before Dubbo can use fastjson2.

### Workaround

Setting the following system property avoids the issue:

System.setProperty("dubbo.json-framework.prefer", "fastjson2");

### Environment

- Dubbo version: 3.3.6
- JDK version: 25
- Works on: JDK 21
- Registry: Nacos
- Gson dependency: not present

### What you expected to happen

Intercept exceptions, skip processing

### Anything else

_No response_

### Do you have a (mini) reproduction demo?

- [ ] Yes, I have a minimal reproduction demo to help resolve this issue more effectively!

### Are you willing to submit a pull request to fix on your own?

- [ ] Yes I am willing to submit a pull request on my own!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

Contributor guide

Open the contributing guide

Research direction

Start with org.apache.dubbo.common.utils.JsonUtils, especially loadExtensions and createJsonUtil, and trace the ServiceLoader path shown in the stack trace. Reproduce on JDK 25 without Gson, compare with JDK 21, and verify that startup succeeds with fastjson2 selected without requiring the system-property workaround.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend, distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.