Introduce a unified Virtual Threads friendly API
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- java
- Domain
- api, backend-api-design
Research direction
Start by reviewing the existing Sync and Async APIs and the current module hierarchy, then compare their Reactor and Reactive Streams dependencies with the proposed Java 21+/25+ direction. The issue provides no files or tests to run; progress means producing and discussing a prototype that meets the listed Virtual Threads, streaming, extensibility, and dependency requirements and reaches community consensus.
Written by the indexing model from the issue text.
Description
The MCP Java SDK team and myself would like to acknowledge the strong desire to evolve the MCP Java SDK to leverage Virtual Threads as a key building block.
This issue is about introducing a new unified Virtual Threads friendly API with the following characteristics:
- Natively designed for Virtual Threads both in terms of idiomatic API and implementation
- Designed with Structured Concurrency in mind but SC will not be required
- Introduce a new way to expose streaming based features
- Extensible design that should allow changing the implementation
- No dependency on Reactor or Reactive Streams
- No
SyncorAsyncprefix - Technically could run on Java 21+ but Java 25+ (latest LTS version without the thread pinning issue) will be the recommended baseline
The Sync and Async API and implementation would remain close to what they are today for now, to not break existing use cases and remain fully compatible with Java 17+, while the new unified API would potentially mean a changed module hierarchy where Project Reactor is not a required dependency.
A prototype of this unified Virtual Threads friendly API, using the Sync API as the starting point but achieving the characteristics shared above, will be shared in this issue or via a related PR and discussed with the community to gather feedback and hopefully reach a consensus.
- Dominant language
- Java
- Stars
- 3.7k
- Forks
- 1.1k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/java-sdk
-
area/transport bug P2
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
modelcontextprotocol/java-sdk#1136 ·
-
area/client bug P2
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
modelcontextprotocol/java-sdk#1124 · 1 comment ·
-
ServerCapabilities.logging is added unconditionally, overriding the caller's explicit capabilities Openbug P2 ready for work
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelcontextprotocol/java-sdk#1086 · 1 comment ·
-
enhancement good first issue P3
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
modelcontextprotocol/java-sdk#1067 ·
-
bug P2 ready for work
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
modelcontextprotocol/java-sdk#898 · 1 comment ·
All issues in modelcontextprotocol/java-sdk
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
FasterXML/jackson-databind#6229 ·