DEV Community: カイノヴァイイ

Why I Replaced ActiveJDBC With My Own ORM

カイノヴァイイ — Wed, 25 Mar 2026 20:32:17 +0000

Why I Replaced ActiveJDBC With My Own ORM

I'm building Obsidian, a Java web framework. The database layer used to run on ActiveJDBC. Then I ripped it out and wrote my own.

Not because ActiveJDBC is bad. But because a framework that depends on another framework isn't really in control of itself.

The Problem With ActiveJDBC

ActiveJDBC lets you write User.where("active = ?", 1) — but Java has a fundamental issue: an inherited static method doesn't know which subclass it's being called from. Model.where() can't figure out on its own that it should query the users table.

To work around this, ActiveJDBC rewrites your .class files after compilation — injecting static methods directly into each subclass. In practice: a mandatory Maven/Gradle plugin running in the process-classes phase, a build step that can silently break when your toolchain changes, and an onboarding experience where the first question is always "why isn't my model working?".

For a personal project, that's fine. For a distributed framework, it's a dealbreaker.

The other reason: dependencies as liabilities. My long-term goal is for Obsidian to run on Spark Java and nothing else. Every library removed is one less thing that can go wrong.

What It Looks Like Now

An Obsidian model is a class that describes itself — no bytecode manipulation, no plugin, just methods:

@Table("game_users")
public class User extends Model {

    @Override
    public String primaryKey() { return "UUID"; }

    public BelongsTo<StaffRank> staffRank() {
        return belongsTo(StaffRank.class, "StaffRankID");
    }

    public HasOne<FactionPlayer> factionPlayer() {
        return hasOne(FactionPlayer.class, "UUID");
    }
}

Table resolution happens through a metadata cache initialized on first access — @Table annotation or derived from the class name. Zero build-time magic.

The Repository Pattern

The model alone isn't enough — you don't want query logic scattered all over the codebase. Obsidian pushes a Repository pattern: a class annotated with @Repository that extends BaseRepository<T> and centralizes all the query logic for a given model.

@Repository
public class UserRepository extends BaseRepository<User>
{
    public UserRepository() {
        super(User.class);
    }

    public User findByUUID(String uuid) {
        return query()
                .with("staffRank", "vipRank")
                .where("UUID", uuid)
                .first();
    }

    public List<User> findByStaffRank(int staffRankId) {
        return query()
                .with("staffRank", "vipRank")
                .where("StaffRankID", staffRankId)
                .get();
    }

    public boolean userExists(String pseudo) {
        return existsWhere("Pseudo", pseudo);
    }
}

@Repository gets picked up at startup by the component scanner and registered in the DI container. Any controller or service can then receive it via @Inject — no manual instantiation.

With ActiveJDBC, queries lived anywhere. Now they have a home:

// Before — ActiveJDBC, scattered across the codebase
List<User> users = User.where("active = ?", 1).orderBy("name").limit(10).load();

// After — Obsidian, centralized in the repository
List<User> users = userRepository.findAll();

Migrations stay fluent:

public class CreateUsersTable extends Migration {
    @Override
    public void up() {
        createTable("users", t -> {
            t.id();
            t.string("name").notNull();
            t.string("email").unique().notNull();
            t.boolean_("is_admin").defaultValue(false);
            t.timestamps();
            t.softDeletes();
        });
    }

    @Override
    public void down() {
        dropTable("users");
    }
}

Blueprint adapts its output for MySQL, PostgreSQL and SQLite through a Grammar abstraction — no hardcoded dialect in the migrations.

Conclusion

The instrumentation plugin is gone from the build. The ActiveJDBC dependency — and everything it pulled in — gone.

The ORM I have now is entirely mine. When something breaks, I read my own code. When I need a feature, I add it.

The lesson isn't "never use third-party libraries." It's that some dependencies sit at the core of what you're building — and at that depth, owning the code is worth the investment.

Obsidian is open source at github.com/obsidian-framework.

Reactive UI in Java Without JavaScript — How I Built Livewire for the JVM

カイノヴァイイ — Thu, 19 Mar 2026 21:56:55 +0000

I run a Minecraft server called SyperCraft. The website has player directories, faction pages, live search with filters — the kind of stuff you'd normally reach for React or Vue to build.

But the backend is Java. And I really, really didn't want to maintain a separate JavaScript frontend just to make a search bar filter results in real-time.

So I built LiveComponents — a server-side reactive UI system for Java, inspired by Laravel Livewire. No JavaScript to write. No API endpoints to wire up. Just a Java class and an HTML template.

It's part of Obsidian, the framework I introduced in my last post.

The idea in 30 seconds

You write a Java class with @State fields and @Action methods. You write an HTML template that references them. Obsidian handles the rest — when the user clicks a button or types in an input, the component calls the server, re-renders, and patches the DOM. No JS to write.

@LiveComponentImpl
public class Counter extends LiveComponent {

    @State
    private int count = 0;

    @Action
    public void increment() { count++; }

    @Action
    public void decrement() { count--; }

    public int getCount() { return count; }

    public String template() {
        return "components/counter.html";
    }
}

<div live:id="{{ _id }}">
    <h2>Count: {{ count }}</h2>
    <button live:click="increment">+</button>
    <button live:click="decrement">-</button>
    <div live:loading>Updating...</div>
</div>

Drop it in your page with one line:

{% component 'Counter' %}

That's the counter example. But counters are boring. Let me show you what this looks like on a real project.

A real example: live player search

On sypercraft.fr/joueurs, players can search through the server's member list. They type a name, pick a rank filter, toggle online/offline status — and the results update instantly. No page reload.

Here's what the component looks like (simplified):

@LiveComponentImpl
public class PlayerSearch extends LiveComponent {

    @State
    private String search = "";

    @State
    private String rank = "all";

    @State
    private String status = "all";

    @Inject
    private PlayerRepository playerRepo;

    @Action
    public void selectRank(String rank) {
        this.rank = rank;
    }

    @Action
    public void selectStatus(String status) {
        this.status = status;
    }

    public List<Player> getFilteredPlayers() {
        return playerRepo.search(search, rank, status);
    }

    @Override
    public String template() {
        return "components/player-search.html";
    }
}

And in the template:

<div live:id="{{ _id }}">
    <input
        live:model="search"
        live:debounce="300"
        type="text"
        placeholder="Search a player..."
        value="{{ search }}"
    >

    <div class="filters">
        <button live:click="selectRank('all')">All ranks</button>
        <button live:click="selectRank('Moderator')">Moderator</button>
        <button live:click="selectRank('Admin')">Admin</button>
        <!-- ... -->
    </div>

    <div class="results">
        {% for player in filteredPlayers %}
        <div class="player-card">
            <img src="https://mc-heads.net/avatar/{{ player.name }}">
            <span>{{ player.name }}</span>
        </div>
        {% endfor %}
    </div>

    <div live:loading>Searching...</div>
</div>

That's it. The search input uses live:model with a 300ms debounce — every keystroke triggers a server round-trip, but only after the user stops typing. The rank and status buttons use live:click to call actions. The whole component re-renders server-side and the DOM gets patched.

No fetch calls. No useState. No useEffect. Just Java and HTML.

How it works under the hood

LiveComponents aren't magic. The system is simple, and that's the point.

1. The client runtime

When the page loads, a small JavaScript runtime is automatically injected before </body> by the framework's template engine — you don't add any script tag yourself. It scans the DOM for elements with live:id attributes, registers each component, and attaches event listeners: click handlers for live:click, input listeners with debouncing for live:model, polling timers for live:poll, form handlers for live:submit.

2. User interaction → POST to server

When the user types or clicks, the runtime sends a POST request to /obsidian/components:

{
    "componentId": "player-search-a1b2c3",
    "action": "selectRank",
    "state": { "search": "Aria", "rank": "all" },
    "params": ["Moderator"]
}

The state is captured from the current DOM inputs. The action name and params are parsed from the attribute — even method-style calls like selectRank('Moderator') work out of the box. The endpoint is CSRF-protected and rate-limited.

3. Security layer

This is the part I care about the most. Server-side rendering means the server is in control, but you still need to be careful about what the client can do.

@Action is mandatory. Only methods explicitly annotated with @Action are callable from the client. If a method doesn't have the annotation, the server rejects the call. This closes the implicit security gap where any public method could be invoked by crafting a request.

@ServerOnly protects sensitive state. Fields annotated with @State @ServerOnly are excluded from client-side hydration — the hydrate() method skips them entirely. The client never sees them, can never override them.

@State
@ServerOnly
private Long userId; // client cannot forge this

Lazy mount is restricted. The mount endpoint checks componentManager.isRegistered() before instantiating anything — you can't trick the server into mounting arbitrary classes.

4. Mounting a component

When a component is first rendered (via {% component 'PlayerSearch' %} in a template), the framework:

Creates a new instance of the component class
Injects @Inject dependencies (repositories, services) via the DI container
Injects @Prop values if passed from the template (e.g. {% component 'UserCard' with { userId: user.id } %})
Calls onMount() — your initialization hook, runs once
Caches the instance in a per-session Caffeine cache (keyed by sessionId:componentId, expires after 1 hour)
Captures the state snapshot and renders the Pebble template

Props use @Prop instead of @State — they're injected at mount time only and never part of the client state:

@Prop
private int userId;

5. Handling subsequent actions

When the user interacts with an already-mounted component, the server:

Retrieves the cached component instance from the session cache
Hydrates the @State fields from the client-sent state (skipping @ServerOnly fields)
Re-injects the HTTP request and @Inject dependencies
Executes the @Action method
Calls onUpdate() — your post-action hook, runs after every action
Captures the new state snapshot
Re-renders the Pebble template and returns the HTML

The runtime swaps the component's DOM node. One detail I'm proud of: it preserves focus and cursor position after re-render. If you're typing in a search field, the cursor stays exactly where it was. Annoying to get right, but it matters.

6. Action responses

Actions don't just update state. They can return a ComponentResponse to trigger side effects:

@Action
public ComponentResponse save() {
    // persist, then redirect
    return redirect("/dashboard");
}

@Action
public ComponentResponse delete() {
    // remove, then notify the client
    return emit("toast:show", Map.of("message", "Deleted"));
}

Redirects navigate the browser. Events are dispatched as CustomEvent on the document — you can listen for them in other components or in a small script if needed.

7. Loading states are automatic

Anything with a live:loading attribute is shown during the round-trip and hidden after. Buttons with live:click get disabled automatically to prevent double-clicks. No extra code.

The directive cheat sheet

Here's what you can do without writing a single line of JavaScript:

Directive	What it does
`live:click="method"`	Calls a server action on click
`live:click="method('arg')"`	Same, with parameters
`live:model="field"`	Two-way binding on inputs
`live:debounce="300"`	Debounces model updates (ms)
`live:submit="method"`	Handles form submission
`live:loading`	Shows element during server call
`live:loading.add="opacity-50"`	Adds CSS class during loading
`live:confirm="Sure?"`	Shows confirmation before action
`live:poll="5s"`	Auto-refreshes every 5 seconds
`live:init="method"`	Calls action on component mount
`live:lazy="ComponentName"`	Lazy-loads component after page render
`live:enter`	Triggers model update only on Enter
`live:blur`	Triggers model update only on blur

The live:lazy directive is useful for heavy components. Instead of blocking the page render, the component loads asynchronously after mount:

<div live:lazy="PlayerSearch"></div>

You can even pass props — to lazy-loaded components via live:props, or to regular components via the {% component %} tag:

{% component 'UserCard' with { userId: user.id } %}

What this is NOT

Let me be clear about the tradeoffs:

It's not a replacement for React/Vue. If you need complex client-side state, offline support, or 60fps animations — use a JS framework.
It's not WebSocket-based. Every interaction is a plain HTTP POST. Simple, debuggable, no connection to maintain.
It adds latency. Every action is a server round-trip. For most CRUD apps, dashboards, and admin panels, you won't notice. For a real-time game UI, you will.
It's server-rendered. Your server does more work. For a Minecraft server website with moderate traffic, that's fine. For millions of concurrent users, think twice.

The sweet spot? Server-rendered apps where you need interactivity but don't want the complexity of a JS build pipeline. Internal tools, dashboards, CMS pages, game server websites. The stuff that makes up 80% of web apps but gets over-engineered with SPAs (Single Page Applications — the React/Vue/Angular model where everything runs client-side).

Try it

LiveComponents are part of Obsidian, an open-source Java web framework built on Spark Java.

Live demo: obsidian-java.com/demo/live-components — try it right now, no setup needed
Repo: github.com/obsidian-framework
LiveComponents examples: github.com/obsidian-framework/livecomponents-examples
Docs: obsidian-java.com/docs

If you've ever thought "I just want a reactive search bar without setting up a whole Node toolchain" — this might be your thing.

Star the repo if you want to follow along. Open an issue if something breaks.

I was tired of Spring Boot, so I built a Laravel-inspired Java framework

カイノヴァイイ — Wed, 18 Mar 2026 05:42:55 +0000

I'm a self-taught developer. I'm 25 and I just want to build things — Minecraft server websites, dashboards, portfolios — without spending half my time fighting my own stack.

That's how Obsidian was born.

The problem

I tried Spring Boot with Thymeleaf. It felt horrible. Too much configuration, too many annotations before writing a single line of business logic. I knew Laravel and Symfony from PHP — and the contrast was brutal.

In Laravel, you clone a repo, run one command, and you're building. In Spring Boot, you're still configuring beans.

I wanted that Laravel feeling, but in Java. I couldn't find it. So I built it.

What is Obsidian?

Obsidian is a web framework built on top of Spark Java that brings Laravel-style conventions to the JVM.

git clone https://github.com/obsidian-framework/obsidian my-app
cd my-app
mvn clean package exec:java

That's it. App running on localhost:8888.

How it feels in practice

Annotation routing

No manual wiring. You declare routes directly on your methods.

@Controller
public class PostController extends BaseController {

    @GET("/posts")
    private Object index(PostRepository repo) {
        return render("posts/index.html",
            Map.of("posts", repo.findAll()));
    }

    @POST("/posts")
    private Object store(Request req, Response res) {
        // handle form submission
    }
}

Dependency injection — two ways

Field injection when you need it across multiple methods:

@Controller
public class ArticleController extends BaseController {

    @Inject
    private ArticleRepository articleRepo;

    @GET("/articles")
    private Object index(Request req, Response res) {
        return render("articles/index.html", Map.of("articles", articleRepo.findAll()));
    }

    @DELETE("/articles/:id")
    private Object delete(Request req, Response res) {
        articleRepo.delete(req.params(":id"));
        res.redirect("/articles");
        return null;
    }
}

Method parameter injection when only one route needs it:

@GET("/articles")
private Object index(Request req, Response res, ArticleRepository repo) {
    return render("articles/index.html", Map.of("articles", repo.findAll()));
}

Fluent migrations

Laravel-inspired schema builder. No raw SQL.

public class CreatePostTable extends Migration {

    @Override
    public void up() {
        createTable("posts", table -> {
            table.id();
            table.string("title").notNull();
            table.text("body");
            table.timestamps();
        });
    }
}

LiveComponents

This is the part I'm most proud of. Reactive server-side UI without writing JavaScript — the runtime is included automatically via {{ livecomponents_scripts | raw }}, inspired by Laravel Livewire.

@LiveComponentImpl
public class Counter extends LiveComponent {

    @State
    private int count = 0;

    @Action
    public void increment() { count++; }

    @Action
    public void decrement() { count--; }

    public int getCount() { return count; }

    public String template() {
        return "components/counter.html";
    }
}

{{ component('Counter') | raw }}

<div live:id="{{ _id }}">
    <h2>Count: {{ count }}</h2>
    <button live:click="increment">+</button>
    <button live:click="decrement">-</button>
    <div live:loading>Updating...</div>
</div>

I use this in production on a Minecraft server website. It works.

How it compares to Spring Boot

	Spring Boot	Obsidian
Time to first route	10+ minutes	30 seconds
Annotations to start	3–5	1
Config files	Multiple	`.env`
Learning curve	Steep	Minimal
Production-ready	Yes	Side projects & small apps

What it's built on

Spark Java — lightweight HTTP server
Pebble — Jinja2-inspired template engine
Reflections — classpath scanning for auto-discovery
Jedis — Redis support via the cache system

Who is it for?

Honestly? Not for enterprise teams that need Spring Boot's ecosystem. Obsidian is for:

PHP developers forced to write Java who miss Laravel
Developers who want to ship a small Java app without the ceremony
Anyone who thinks Java web dev should feel less like paperwork

What's next

The framework is MIT licensed, the code is open, and I'm building in public. There will be bugs. I'll fix them.

If this sounds interesting — the repo is at github.com/obsidian-framework and the docs are at obsidian-java.com.

Star it if you want to follow along. Open an issue if something breaks. That's how open source works.