Detailed breakdown The libraries
One card per option. For each: what it is, what it does well, what it doesn't, the
exact Maven coordinates when applicable, and a representative code example.
Message window persistence with a pluggable store
Chat History Active Java Apache 2.0 ★ 9,000
The most popular LLM library on the JVM. Ships a ChatMemory interface with MessageWindowChatMemory and TokenWindowChatMemory implementations. Persistence is bring-your-own via the ChatMemoryStore interface.
dev.langchain4j:langchain4j:1.0.0
What it does well
- Mature, well-documented, widely adopted
- Clean abstraction for message history
- Pluggable storage via ChatMemoryStore
- Token-aware window eviction
Where it stops
- No fact extraction — it is a message container
- No semantic search built in (RAG is a separate subsystem)
- Every team implements their own knowledge layer on top
ChatMemory chatMemory = MessageWindowChatMemory.withMaxMessages(20);
chatMemory.add(UserMessage.from("I'm allergic to peanuts"));
chatMemory.add(AiMessage.from("Got it, I'll remember that."));
// Next session: chatMemory is empty unless ChatMemoryStore is implemented
Message history with the broadest backend coverage
Chat History Active Java Apache 2.0 ★ 6,000
Spring AI's ChatMemory shipped GA in 2025 with JDBC (Postgres, MySQL, Oracle, SQL Server), Cassandra, Mongo, Neo4j, and Cosmos DB backends. Three advisors plug it into ChatClient. The VectorStoreChatMemoryAdvisor indexes raw messages in a VectorStore but does not extract facts.
org.springframework.ai:spring-ai-core:1.0.5
What it does well
- Broadest backend support of any JVM memory library
- Cassandra support includes TTL
- Tight Spring Boot integration
- VectorStoreChatMemoryAdvisor enables RAG-style message recall
Where it stops
- Indexes raw messages, not extracted facts
- No entity model or relationship graph
- No conflict detection
- Community examples describe building fact extraction yourself with a "recorder advisor" pattern
ChatMemory chatMemory = MessageWindowChatMemory.builder()
.chatMemoryRepository(new JdbcChatMemoryRepository(jdbcTemplate))
.maxMessages(20)
.build();
ChatClient client = ChatClient.builder(chatModel)
.defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build())
.build();
Vertex AI Memory Bank or keyword matching
Framework Active Java Apache 2.0 ★ 2,000
Google's Agent Development Kit shipped 1.0.0 for Java in 2025 with a BaseMemoryService interface. Two implementations: InMemoryMemoryService (keyword matching only, for development) and VertexAiMemoryBankService (fully managed, Vertex AI only). Memory Bank does real fact extraction but is Google Cloud-locked.
com.google.adk:google-adk:1.0.0
What it does well
- Memory Bank is a real managed memory service with fact extraction
- Session services with Firestore and Vertex backends
- Native Gemini integration
- LangChain4j integration for other model providers
Where it stops
- Semantic memory requires Vertex AI (vendor lock-in)
- OSS path (InMemoryMemoryService) is keyword matching over a HashMap
- No self-hosted option for real memory
- Pricing is per-API-call
Memory Bank is genuinely good, but you pay for it in cloud lock-in.
JetBrains fact store, Kotlin-first
Framework Active Kotlin Apache 2.0 ★ 1,500
JetBrains' JVM agent framework with a dedicated AgentMemory feature that stores facts organized by Concept, Subject (user, product, organization), and Scope. The nodeSaveToMemoryAutoDetectFacts node uses an LLM to extract facts automatically. Closest competitor to Mem0/Zep on the JVM.
What it does well
- Dedicated AgentMemory feature with Concept/Subject/Scope model
- LLM-based fact extraction out of the box
- Persistence providers for in-memory, file, and Postgres
- Active JetBrains maintenance
Where it stops
- Kotlin-first — Java consumption is awkward
- Issue #1001: AgentMemory floods prompts as facts accumulate (no token budgeting)
- No conflict detection for updating/contradicting facts
- No temporal validity or decay
agent {
memory {
scope = MemoryScope.User("user_123")
}
nodeSaveToMemoryAutoDetectFacts {
subjects = listOf(Subject.User, Subject.Product)
}
}
See JetBrains/koog#1001 for the known scaling issue with AgentMemory replay.
Blackboard pattern, long-term memory is a non-goal
Framework Active Kotlin / Java Apache 2.0 ★ 3,000
Rod Johnson's (Spring creator) JVM agent framework. Uses Goal-Oriented Action Planning with a blackboard state container for domain objects passed between actions during an agent run. Per the maintainers, long-term conversational memory is explicitly out of scope.
com.embabel.agent:embabel-agent-starter
What it does well
- Strong agent orchestration with goal-oriented planning
- Clean blackboard pattern for domain objects within a run
- Full Java interop from Kotlin core
- Spring-integrated
Where it stops
- Per-run blackboard, not persistent across sessions
- Long-term memory is an explicit non-goal
- Use Embabel for orchestration, bring memory separately
Per maintainers: "in Embabel it's not about conversational memory so much as domain objects that are stored in the blackboard during the flow."
Thin REST client, requires Python Mem0 server
Framework Java MIT ★ 9
The top Google result for "Mem0 Java SDK" is me.pgthinker:mem0-client-java, a community REST wrapper. It is not an SDK in the meaningful sense — it requires running a Python Mem0 server alongside your JVM application, with its own Qdrant and graph database dependencies.
me.pgthinker:mem0-client-java:0.1.3
What it does well
- Wraps a real memory engine (Mem0) via HTTP
- Inherits Mem0 Python features through the sidecar
Where it stops
- 9 GitHub stars, 13 total commits, last updated ~9 months ago
- Not an official SDK — Mem0 ships Python and Node.js only
- Requires running Python Mem0 server alongside your JVM application
- Inherits Mem0 infrastructure dependencies (Qdrant + graph DB typically)
- No SLAs, no roadmap, unmaintained
Not a serious production option for JVM teams. If you want Mem0, either pay for Mem0 Cloud or accept the Python sidecar.
Does not exist
Does Not Exist Does not exist — —
Zep's official clients are Python, TypeScript, and Go. There is no Java SDK at any state of completeness. Java teams who want Zep's temporal knowledge graph must either consume Zep Cloud over HTTP or hand-roll a REST client.
Where it stops
- No Java SDK exists
- Python, TypeScript, and Go only
- JVM teams must hand-roll HTTP clients
Graphiti (Zep's engine) scored 63.8% on LongMemEval-S in published results. Zep's earlier 84% LoCoMo claim was re-evaluated to 58.44% by independent testing (getzep/zep-papers#5). Neither number is reachable from Java without a sidecar.
The most common Java AI memory stack in production today
DIY Active Java N/A
Most Java teams that need real memory assemble their own: PostgreSQL with pgvector (or Qdrant) for embeddings, JdbcChatMemoryRepository for raw messages, a custom advisor that calls an LLM to extract facts, and a cron job for decay. Roughly 1,500–3,000 lines of bespoke Java per team.
What it does well
- Full control over every layer
- Uses well-known components (Postgres, pgvector, Jackson)
- No new vendor dependency
- Can be shaped to exact requirements
Where it stops
- 1,500–3,000 lines of custom code to maintain
- Quietly diverges between teams and projects
- Rarely gets temporal reasoning right
- Almost never gets consolidation right
- No common benchmark to validate against
Fact extraction, hybrid retrieval, consolidation — in one dependency
Memory Layer Active Java / Rust Apache 2.0 ★ 5
A durable memory system for AI agents from the JamJet project. Does fact extraction with conflict detection, hybrid retrieval (vector + SQLite FTS5 keyword + graph walk), temporal knowledge graph, token-budgeted context assembly, and a 5-operation consolidation engine (decay, promote, dedup, summarize, reflect). Runs against SQLite by default.
dev.jamjet:jamjet-sdk:0.4.3
What it does well
- Only library on this list with fact extraction + hybrid retrieval + temporal graph + consolidation in one dependency
- Zero infrastructure — SQLite only, no Postgres, no Qdrant, no Neo4j, no Python sidecar
- Spring Boot starter with auto-configuration (engram-spring-boot-starter:0.1.1)
- MCP server option means the same store is reachable from non-JVM agents
- Published on Maven Central, Apache 2.0
Where it stops
- Version 0.4.3 — new project, small community
- No JDBC backend yet (SQLite-first, Postgres planned for 0.5.x)
- No published LongMemEval or DMR benchmark scores yet
- 5 GitHub stars — you will be an early adopter
try (var memory = new EngramClient(EngramConfig.defaults())) {
memory.add(
List.of(
Map.of("role", "user", "content", "I'm allergic to peanuts"),
Map.of("role", "assistant", "content", "Got it.")
),
"alice", null, null
);
var context = memory.context(
"what should I cook for dinner",
"alice", null, 1000, "system_prompt"
);
System.out.println(context.get("text"));
}
This site is maintained by the JamJet team. Engram is their project. We have tried to present it with the same honesty we apply to every other library here — including the gaps. Pull requests correcting any inaccuracy are welcome.