DEV Community: Svetozar Radojcin

TabForge AI: a complete platform for building Java Web + AI apps

Svetozar Radojcin — Tue, 11 Aug 2026 12:18:56 +0000

Modern AI UX — chat panels, tool-calling agents, assistants that remember context and even suggest your next step — has lived in JavaScript SaaS for years. The Java enterprise stack has been left doing it the hard way.

TabForge AI closes that gap. It's a complete platform for building AI-powered web apps on Jakarta EE + PrimeFaces — from the multi-tab UI shell down to a clean, provider-agnostic AI layer. Library, live demo, starter project, and a drop-in UI template — all shipped.

Here's the whole thing, top to bottom.

## 1. Tabs as annotated beans — DynTabs

You describe a tab; the framework handles opening, closing, lifecycle, and state. Each open tab gets its own isolated CDI bean via a custom @TabScoped scope.

  @Named
  @TabScoped
  @DynTab(name = "OrdersDynTab", uniqueIdentifier = "Orders",
          title = "Orders", includePage = "/WEB-INF/orders.xhtml",
          trackActivity = true)
  public class OrdersBean extends BaseDyntabCdiBean {
      // open the same tab twice → two independent instances
  }

java
No manual navigation, no page-state juggling. Open a tab, get a bean; close it, it's gone.

A clean AI layer — EasyAI

One fluent entry point over LangChain4j. Chat, tools, agents, and structured extraction — provider-agnostic, so the model behind it is a config detail.

  // A typed assistant with a business service exposed as tools
  OrdersAssistant ai = EasyAI.assistant(OrdersAssistant.class)
          .withTools(orderService)
          .build();

  String reply = ai.ask("cancel order ORD-002");

You opt methods in as tools explicitly — no accidental exposure:

  @EasyTool("Cancels an active order")
  public String cancelOrder(String orderId) { ... }

Deterministic pipelines — flow()

Agents are powerful but unpredictable. When you want a repeatable, testable process, flow() lets you own the steps and call the model only at the edges that actually need language:

 EasyAI.flow()
      .step("understand", ctx -> EasyAI.extract(OrderRequest.class).from(ctx.inputText()))
      .step("checkStock", ctx -> inventory.check(ctx.get("understand", OrderRequest.class)))
      .step("place",      ctx -> orders.place(ctx.get("understand", OrderRequest.class)))
      .build()
      .run(userText);

Your logic stays in plain Java. The LLM does one job: turn language into structure.

Ambient Activity Memory

The framework quietly records what the user does in the app — opening a record, running a search — and makes that timeline available to the assistant. So deixis just works:

  @ActivityTracked(type = BUSINESS_ACTION, verb = "view",
                   entityType = "order", entityIdParams = "orderId")
  public String viewOrder(String orderId) { ... }

Now the user can open an order and type "cancel this" — no id — and the assistant resolves "this" from what it just
saw them do.

The proactive assistant

This is the piece you normally only see in Copilot, Gmail's Smart Compose, or Notion AI — and almost never as a first-class pattern in a Java web framework.

Built on Ambient Memory, the app can offer the next useful step before you ask. Open two orders for the same customer, and a dismissible chip appears: "Looking at several Acme orders — want a quick account summary?"

The important part: it's not a black-box agent watching you. A small, deterministic rule — plain Java you write and unit-test — decides if and what to suggest. The model only phrases the sentence.

  public interface SuggestionRule {
      Optional<Suggestion> evaluate(List<UserActivityEvent> recent);
  }

Detect synchronously (cheap, predictable), phrase-and-push asynchronously, with a per-user cooldown so it's helpful and never naggy. Deterministic code decides; the model is reserved for the one thing it's good at.

The UI, handled — pf-modern-template

A self-contained PrimeFaces template: responsive layout, light/dark/dim themes, a transport-agnostic AI panel (chat + live activity over SSE), a command palette, and now proactive suggestion chips. Drop-in — no build dependency.

Getting started

The fastest path is the starter — a pre-wired WAR you clone and deploy. Or add the library to an existing Jakarta EE 11+ project:

  <dependency>
      <groupId>io.github.tabforgeai</groupId>
      <artifactId>tabforge-ai</artifactId>
      <version>3.1.0</version>
  </dependency>

Chat- and tools-only apps stay lean; RAG and vector-store integrations are optional add-ons you pull in only if you use them.

The philosophy

One idea runs through all of it: let deterministic code decide, and reserve the model for the irreducible — language. That's what makes AI in a serious enterprise app predictable, testable, and safe.

Proactive UX just arrived, first-class, in the Java stack.

The library
demo app
ready to use starter
See it in action

All OpenSource

Teaching an AI to read a relational database — including Oracle APEX

Svetozar Radojcin — Wed, 22 Jul 2026 07:49:26 +0000

A few months back I started building a tool to solve a problem that kept
annoying me: when you want an AI assistant to help with an old database, you end up as a human clipboard — copying schema, pasting stored procedures, describing foreign keys by hand. The AI never actually sees the database.

So I built Legacy SQL Architect MCP — an MCP server that connects Claude (or any MCP-compatible client) directly to your PostgreSQL, SQL Server, or Oracle database, in strict read-only mode. The AI inspects the real thing instead of guessing from what you paste.

## The core idea

Once connected, the assistant can use a set of tools to explore the database on its own:

| Tool | What it does |
|------|--------------|
| inspect_schema | Tables, columns, types, primary & foreign keys |
| data_sampler | Sample rows, with automatic masking of sensitive columns |
| get_procedure_source | Full source of stored procedures and functions |
| query_plan_expert | Execution plan analysis, full-scan detection |
| dependency_graph | FK chains, trigger → procedure call chains, view deps |
| generate_mermaid_erd | An ER diagram in Mermaid |
| generate_documentation | Complete Markdown docs for the whole schema |
| find_impact | Everything that depends on a given table |
| generate_java_dao | Ready-to-compile Java Entity + Repository classes |

So you can say things like:

"Inspect the schema, sample the orders table, read the procedures that touch it, and tell me what would break if I rename order_status."

…and the assistant actually goes and looks, then answers with references to real objects. Read-only by design — it physically cannot INSERT, UPDATE, or DELETE.

## The new part: Oracle APEX

This is the release I want to talk about, and I'll be honest about how it came to be.

I'm not an APEX developer. I've never shipped a production APEX app. But APEX performance problems are notoriously hard to see, and it turns out Oracle exposes a lot about an APEX application through its own dictionary views —
APEX_APPLICATIONS,APEX_APPLICATION_PAGE_REGIONS,APEX_APPLICATION_LOVS, APEX_WORKSPACE_ACTIVITY_LOG, APEX_DEBUG_MESSAGES, and friends. The answer to "why is this page slow?" is often sitting right there.

So I studied those views and turned them into six tools that hand that insight to the AI in a form it can reason about. Every one was verified against a live APEX 26.1 instance before shipping.

### inspect_apex_performance
An overview of an application: pages, regions with SQL, LOVs, validations, processes — plus the slowest pages by real user activity, and a list of recommendations (slow pages, SELECT * regions, LOVs with no WHERE clause, unconditional processes, …).

"Run inspect_apex_performance on app 102 and show me the 5 slowest pages and why."

### get_apex_source
The APEX counterpart to get_procedure_source: it extracts the embedded code across 12 component types (regions, processes, computations, validations, items, branches, dynamic actions, LOVs, authorizations, …). It introspects each view's columns first, so it tolerates dictionary drift between APEX versions.

"Get the source of every SQL region on page 3 and summarize what they query."

### inspect_apex_debug
Reads APEX_DEBUG_MESSAGES, reconstructs page views by grouping on the page-view id, finds the slowest ones, and drills into the individual steps — so you can see where inside a page render the time actually went.

"Which page views in the last 2 days were slowest, and what step dominated?"

### apex_config_audit
A static anti-pattern audit — no runtime data needed:

pagination schemes that force a COUNT(*) ("row N of Z")
reports with unbounded / very high max-rows
frequently-used LOVs with no caching
pages with too many server-side dynamic actions
pages crowded with many SQL regions

"Audit app 102 for configuration anti-patterns."

### apex_sql_runtime_stats
Correlates the app to its real runtime cost by reading V$SQL for the app's parsing schema — buffer gets, elapsed time, executions — and flags the hot SQL.

"What's the most expensive SQL this app has actually run? Order by buffer gets per execution."

### apex_explain_batch
Runs EXPLAIN PLAN across an app's SQL regions, SQL LOVs, and Exists-type validations at once, then flags the red lines: TABLE ACCESS FULL,
MERGE JOIN CARTESIAN, INDEX FULL SCAN. (It handles APEX &SUBSTITUTION. tokens by binding them, so the plans actually parse.)

"Explain-plan all the SQL in app 102 and list anything doing a full scan or a Cartesian join."

## None of this is magic

It's all sitting in Oracle's own dictionary. What the tool does is connect the dots and hand them to the AI in a form it can reason about — grounded in your actual application, not a generic "best practices" lecture.

## An honest ask

Because I'm not an APEX expert, I'd genuinely value review from people who are. Am I reading the right views? Is there a metric you always check first that I'm ignoring? Did I get something wrong? You know this platform far better than I do.

It's open source and free (Apache 2.0), with native installers for Windows and Linux (deb + rpm) that bundle their own Java runtime — no JDK needed.

GitHub: https://github.com/tabforgeai/legacy-sql-architect-mcp

If you try it against a real APEX app, I'd love to hear what it found — or where it fell short.

We built a bidirectional context loop between web apps and AI agents

Svetozar Radojcin — Thu, 25 Jun 2026 13:39:49 +0000

Source code: Tabforge AI
Most AI integrations in business apps feel the same:

You send a prompt → the model returns an answer → you try to glue it into your app.

It works, but it always feels slightly disconnected from what’s actually happening in the UI.

The AI doesn’t really know what the user is doing.

And the app doesn’t really know what the AI just did.

We ran into that problem while building EasyAI / TabForge, and ended up with something we didn’t originally set out to build:

a bidirectional context loop between the application and the AI runtime.

The problem: AI in apps is stateless

Even when you pass “context”, it’s usually:

a string
a JSON blob
or a manually assembled prompt

But the real state lives elsewhere:

which record is open
what tab the user is on
what action just happened
what step in a workflow the user is in

So you end up doing things like:

passing IDs around
re-sending state on every request
rebuilding context for every AI call

It works, but it’s fragile.
**
Ambient Activity Memory (App → AI)**

The first thing we added was a way for the application to continuously describe what is happening inside it.

Not as logs.Not as analytics.
But as structured semantic events tied to actual UI actions.

So instead of:

“here is an order id”

the system already knows:

user is currently viewing Order #248
user just switched from payment tab to details tab
user just triggered refund flow

Now when the user says:

“cancel this order”

there is no ambiguity about what “this” refers to. The AI doesn’t guess context.It already has it.

EasyAIEvent (AI → App)

Once the AI started understanding the app state, the next obvious question was:

what does the AI give back to the application?

Not just a final answer, but the execution itself.

So every agent run can optionally emit a structured event stream:

started
planning
tool calls
progress updates
completion This is exposed via a simple hook:

.withEventListener(event -> { log.info("[{}] {} — {}", event.source(), event.phase(), event.title()); })

No framework coupling.No HTTP assumptions.No UI dependencies.
Just a pure event stream that your app can consume however it wants.

What this enables (more interesting part)

Once you have both directions:
App → AI

The system knows what the user is doing.
AI → App

The system exposes what the agent is doing. You end up with something simple but powerful:

a closed loop between UI state and AI execution state
**
Why this matters in practice**

This removes a bunch of glue code that usually creeps into AI integrations:

passing IDs back and forth
manually constructing prompts
debugging “what did the agent actually do?”
rebuilding context on every request

Instead:

the app continuously emits context
the AI continuously emits execution state
both stay decoupled, but synchronized

Important design choice

The event model is intentionally framework-agnostic:
(source, phase, status, title, detail, toolName, sequence, timestamp)

It does not know anything about:

HTTP, WebSockets, SSE, UI frameworks

That part is left to the application.

We ship a minimal example that maps the event stream to a real-time UI panel using SSE, but it stays outside the core library.

Where this is going

The interesting part is not the event system itself. It’s what becomes possible when:

the app knows what the user is doing
the AI knows what it is doing
and both sides share the same runtime context

You start to move from “AI calls inside an app” toward something closer to:

AI as a participant in application execution, not just a function you call

If you strip everything away

At its core, this is all we tried to solve:

How do we make AI systems aware of application state without coupling them to the UI?

And the answer turned out to be:

Don’t pass state. Stream it in both directions.

If you want to explore it:
The AI assistant knows what user doing in the app
AI streams his work details to the app
GitHub: https://github.com/tabforgeai/tabforge-ai
Full example: https://github.com/tabforgeai/tabforge-ai-demo