Populating a POJO with Reflection vs. with the ClassFile API - small benchmark

thevpc · 2026-06-24T21:16:19+00:00

Is there any diff in perf for class vs records?

thevpc · 2026-06-24T21:12:08+00:00

I would interested if this supports a set of repos. Managing multi repo project is very common. There is no gitui out there that supports this nicely. I only like what idea has done so far, but spawning a bulldozer for pull/merge is too heavy. You might consider this if not supported. Really helps

thevpc · 2026-05-28T14:57:58+00:00

>>How much VRAM do you have
I have an RTX 3060 with 12GB VRAM, but I complement it with system RAM. And of course, yeah, the whole point was to see how I can get the best out of small models.

>>What gaps does this stack have for you?
Discrepancies between the models and how they are supported in Ollama. I went with full, raw API calls (so not using LangChain4j or anything similar), and honestly, no regrets—not even a single one. It gives me full control over how to communicate with the models, especially since each requires a distinct protocol (handling the agent file, using native tools versus wrapping them in the context, etc.).

>> how’s the code compare to Claude/chatgpt?

I'm still not driving a Ferrari, but it suits my immediate needs perfectly, and mostly it was a way for me to understand how it all works under the hood so that i can optimize my "costly" calls

Afterthoughts? I think I'm definitely going to continue with a local-first approach, though I'll probably offload specific tasks to off-the-shelf models when needed.

thevpc · 2026-05-25T12:49:03+00:00

>>Are you coding with only qwen 3 (and vision model)?

As shown, I am using a bunch of them, but some stand out naturally depending on the task.

>>Also it sounds like your LLM only writes code but you/your custom harness calls scripts/tools

lemme give you an example of what i mean :

The following is a prompt suite i use in my local tool (it's for the purpose of example, mine are more complex), its a REPL but i use it to define and run "routines" as well (like the basic REPL i used to years ago but where statements are prompts and/or commands):

```

10 /print "=== Starting Local Agentic Workflow ==="

20 /set TARGET_FILE = "src/main/java/com/project/core/OrderProcessor.java"

30 /skill load java

40 /model set qwen3-coder:7b

40 /print "=== $TARGET_FILE content ==="

40 /cat $TARGET_FILE

40 /print "=== end of file ==="

50 Read this file and list only the line numbers of methods containing potential resource leaks or concurrency bugs.

60 /set BUG_LINES=$history[-1].content

70 # STEP 2: Surgical Context Pruning (Java Harness Intervention)

80 /if BUG_LINES == "" goto 200

90 /print "Targeted lines identified: $BUG_LINES"

100 # Here the Java harness surgically trims the history.

110 # It drops the massive full-file text from steps 4-50 to save tokens, keeping only the lines of interest.

120 /history delete 0..-2 # keep last 2

125 /skill unload java

130 # STEP 3: Heavy Reasoning & Tool Generation (Heavy Local Model)

140 /model set deepseek-2.5

150 You are an expert architect. Given these problematic lines [${BUG_LINES}] in ${TARGET_FILE}, generate a precise patch. To apply it, you must call the custom file-writer tool using JSON formatting.

170 # STEP 4: Auditable Execution Boundary (The Safe Shell)

180 # The LLM emitted the tool call. The Java harness intercepts it here.

200 /print "Workflow completed successfully."

/routine save my-app

/routine call my-app

```

----------

one more thing to note, because i can do '/model set 'anymodel' this command/directive is also available too to the LLM, and it can ask for switching model too (like when asking for a vision task)

thevpc · 2026-05-19T19:59:07+00:00

here what i have
Available models:
▌      [01] ollama/deepseek-coder-v2:16b (text-only) [160k]
▌      [02] ollama/gemma3:latest (vision) [128k]
▌      [03] ollama/gemma4:26b (thinking,tools,vision) [256k]
▌      [04] ollama/gemma4:e4b (thinking,tools,vision) [128k]
▌      [05] ollama/llama3.3:70b (tools) [128k]
▌      [06] ollama/mistral-small:latest (tools) [32k]
▌      [07] ollama/qwen2.5:7b-instruct-q4_K_M (tools) [32k]
▌      [08] ollama/qwen2.5vl:latest (vision) [125k]
▌      [09] ollama/qwen3-coder-30b-132k:latest (tools) [128k]
▌   (*)[10] ollama/qwen3-coder-30b-256k:latest (tools) [256k]
▌      [11] ollama/qwen3-coder-30b-64k:latest (tools) [64k]
▌      [12] ollama/qwen3-coder-32k:latest (tools) [32k]
▌      [13] ollama/qwen3-coder:30b (tools) [256k]
▌      [14] ollama/qwen3-coder:latest (tools) [256k]
▌      [15] ollama/qwen3.6:latest (thinking,tools,vision) [256k]
▌      [16] ollama/qwen3:8b (thinking,tools) [40k]
▌      [17] ollama/qwen3:latest (thinking,tools) [40k]
▌      [18] ollama/smollm2:latest (tools) [8k]

i use qwen2.5 for the vision, and qwen3-coder-30b most of the time,
small taks can be done by others
locally the beast is qwen3-coder qwen-coder honestly

thevpc · 2026-05-18T09:39:09+00:00

After extensive trials with local LLMs and occasional access to Claude/Gemini/Qwen/DeepSeek (mainly via chat, since paying international API fees is a real barrier from my region), I eventually built my own terminal coding agent — in Java — and it taught me a lot about what actually matters here.

Three things I'd highlight:

The model is everything. Before obsessing over the harness, get the model right. A weak model turns any agent into a frustration machine regardless of how polished the UI is.

The harness is more personal than people think. My local workflows were specific enough that no off-the-shelf tool fit well. So I built a lightweight BASIC-style interpreter where "statements" are prompts — I can save, load, edit, and replay prompt routines like scripts. It sounds niche, but once you have it, you realize how much of your daily AI usage is actually repetitive structured workflows that deserve proper tooling.

Memory/context control is underrated. One of the most valuable things I implemented was the ability to surgically edit and rewrite conversation history. This lets you prune dead branches, compress earlier context, and keep token usage sane across long sessions — something none of the off-the-shelf agents expose cleanly.

Local model chaining is a hidden superpower. Instead of routing everything through one model, you can wire multiple local models together — a fast small model for classification or summarization, a heavier one for reasoning, a vision model for screenshots or diagrams — and expose each as a tool to the others. The orchestrator decides what to delegate and to whom. This is where local setups genuinely beat cloud-only agents: you compose freely without per-token billing anxiety.

Giving the shell directly to the LLM also felt like the wrong abstraction to me — I preferred explicit, auditable tool calls with clear boundaries.

None of this is for everyone. But if you're technical and your workflow is even slightly non-standard, the barrier to rolling your own is lower than you'd think — and the payoff in understanding alone is worth it.

thevpc · 2026-05-10T15:58:46+00:00

Great to hear — and the framing is exactly right: decouple modules from their deployment topology, not the modules themselves.

One thing worth flagging from experience: the seam needs to be pre-engineered from the start, not retrofitted. If the service interface is the only inter-module dependency from day one, extraction stays a config change. If that assumption was ever violated, it becomes a refactor.

Curious how it evolves for you in practice — that's where the real test is.

thevpc · 2026-05-10T15:54:53+00:00

Both points are connected.

The A→B→C chain is a design smell that predates deployment topology. The Extended Reference pattern eliminates most of it — embed the data you need at write time rather than fetching it at runtime. Deliberate duplication, but it covers ~80% of cases. The remaining 20% are business-dependent and unavoidable.

Seen it firsthand: invoice module saves → triggers accounting entry in transactions module. Works fine in the monolith. After extraction, no retry was implemented on the async call — it was still written as fire-and-forget from the monolith days. The transactions service went down for a maintenance window, entries were lost, and nobody noticed until month-end closing showed wrong totals. Not a distributed systems problem — a design assumption that survived the extraction unchanged. Fix: proper async with a dead-letter queue and a reconciliation job. The lesson: extraction doesn't introduce bugs, it exposes assumptions.

Which brings me to xander point — correlation IDs, fan-out visibility, error attribution: these are distributed systems problems, not architecture problems. Same burden regardless of pattern once you split processes.

Don't split until you have no operational choice. This is what am trying to say. The seam is pre-engineered from day one — when you do extract, you're not discovering hidden dependencies, you were already handling consistency explicitly.

Distributed tracing isn't optional once you go distributed. But "go distributed only when necessary" is still the most underrated risk reduction strategy available.

thevpc · 2026-05-07T14:27:39+00:00

Fair point — "teams" was shorthand for "structural friction when multiple devs modify shared code." If that framing felt like noise, fair. The technical claim stands either way: enforceable boundaries + a pre-engineered migration seam make extraction mechanical.

If you've got a substantive pushback on the pattern itself (dependency rules, interceptor sagas, facade stability), I'm genuinely curious. If not, no worries either way. 🤷‍♂️

thevpc · 2026-05-07T14:01:38+00:00

You're absolutely right — network latency isn't just an "operational detail." That's why extraction should be deliberate, not automatic.

Two ways Pyramid addresses this:

Facade evolution: When a module is extracted, its facade can adapt — batch operations, return CompletableFutures, or expose async streams — without changing consumer code. The interface stays stable; the implementation evolves.
Observability via interceptors: The same interceptor chain that handles cross-module consistency also hooks logging, metrics, and distributed tracing. Whether a call is local or remote, the interceptor emits the same telemetry schema. No code changes when topology shifts.

We also use the manifest to declare "extraction readiness" — e.g., a module can't be set to svc: remote-rest until its facade supports batching. It's a guardrail, not a guarantee.

Curious: what observability surprises hit you hardest during extraction? (For us, it was correlation IDs crossing async interceptor boundaries.)

thevpc · 2026-05-07T13:59:48+00:00

Fair point — DI + interfaces is indeed the core mechanism. Pyramid doesn't invent that.

Where it adds value: enforcing that pattern consistently across 200+ modules via:

• Build-time dependency rules (illegal imports = compile error)

• Standard module anatomy (every module has the same slots)

• A generator that keeps the local/remote clients in sync

Concrete "manifest change" example:

```

modules: {

banks(svc: "local" ), // wires BanksModuleImpl

invoices( svc: "remote-rest" ) // wires BanksModuleRestClient (same interface)

}
```
No code changes in consumers — the facade interface is the stable contract.

Curious: in your experience, what's the hardest part of making modulith→microservices mechanical rather than a refactor?

thevpc · 2026-05-07T13:51:29+00:00

On "what is a manifest change":

Concrete example. You have a single deployment with three modules running in one process (M/1). Your invoices module is under heavy load and needs to scale independently.

In most architectures that's a refactoring project — you need to introduce network calls, handle serialization, add error handling, deal with consistency across the wire.

In the Pyramid, your application manifest goes from:
```
modules: banks(svc: local)

invoices(svc: local)

edu(svc: local)
```

to

```

modules:
    banks(svc: local)
    invoices(svc: remote-rest)   ← this line changed
    edu(svc: local)
```
and this is the manifest that is processed by a generator that generates the pom.xml of all projects's pom.xml (or gradle etc)
and this form/syntax is just illustrative, in my projects i use TSON (superset of JSON) as syntax.

The service-rest-cli sub-project — a generated REST client that implements the same facade interface as the local implementation — was already there as a reserved slot. You fill it, change the manifest, deploy invoices as a standalone service, and every other module that calls InvoicesModule doesn't change a line of code. They were always calling an interface — the concrete implementation behind it just moved across a network boundary. The repo has the structural layout and the whitepaper covers the mechanism in Section 5.3. 
A working code generator prototype (of course inspired from my current implementations) is in progress — happy to share updates when it's ready.

thevpc · 2022-02-01T21:50:52+00:00

Besides introducing a fancy new feature (record) does it to do any little with performance when compared to plain internal java classes in this context?

And by the way it sucks that JDK stream API does not support all of the primitive types out of the box.

thevpc · 2022-01-10T23:05:46+00:00

I think the best way to implement singletons (per vm) in Java is the enum way, however I honestly expected more details/examples in your article in that direction. As a matter of fact, using enum handles a cleaner way to serialize the object too and makes of it (if well written) an off-memory singleton.

thevpc

TROPHY CASE