jBC vs Design Studio in TAFJ: Which One Should You Actually Use?

There is a moment in every TAFC to TAFJ migration where a developer asks this question out loud in a meeting, and three other people nod because they have been wondering the same thing but did not want to be the one to ask. It is the kind of nod that says "I have been trying to figure this out for three days and I am starting to question my career choices."

The question sounds simple: "Should I use jbc or Design Studio?" The honest answer is: it depends on what you are building. The less honest answer — the one that gets people into trouble — is "just use whichever one compiles it." This is technically true in the same way that a brick is technically a flying device if you throw it hard enough.

That second answer is wrong, and it produces a very specific kind of bug: the change that compiles perfectly and does absolutely nothing at runtime. It is the software equivalent of pressing the button on a pedestrian crossing and watching the little red man stay red forever. The system acknowledges your request. It simply has no intention of doing anything about it.

Why the confusion happens

People coming from TAFC expect a simple compile-and-run loop for everything. In TAFC, you edited a routine, ran BASIC, and the change was live. The boundary between "routine logic" and "framework object" was blurry enough that it rarely mattered which one you were touching. You could edit almost anything with a text editor and it worked. It was not elegant, but it was fast. It was the software equivalent of fixing a car with a hammer. It was not the right tool, but it got the job done and nobody asked questions.

TAFJ is not TAFC. It still allows a familiar routine workflow in some areas, but it also introduces a more formal build path for framework-native objects. The difference matters because the wrong tool choice produces changes that appear to compile but never actually take effect. The compile log says "success." The system disagrees. This is the TAFJ equivalent of the Hitchhiker's Guide entry for "compilation": harmless, mostly.

So the question is not "which tool is correct?" The better question is "what kind of artifact am I changing?" If you cannot answer that question, neither tool will help you. You will just be standing there with two perfectly good tools and a change that refuses to exist.

The practical split

What happens when you pick the wrong one

The most common symptom of a toolchain mismatch is a change that compiles successfully but does nothing at runtime. This is not a rare edge case. It is the default outcome of using jbc on a framework object. It is not a bug. It is a feature of not understanding the feature.

Here is how it plays out. A developer edits a version or enquiry definition using a text editor, runs jbc on the file, gets a clean compile, and expects the change to appear. It does not. They check the file. It looks right. They compile again. Still nothing. They try turning it off and on again. Nothing. Somewhere between the third and seventh attempt, someone mentions that framework objects need the Design Studio build pipeline. The developer stares at the screen for a moment, then says something that sounds like "have you tried turning it off and on again?" but with considerably less patience.

The reason is straightforward: framework-managed objects in TAFJ are not loaded from individual compiled files at runtime. They are packaged into component archives through the Design Studio build pipeline — tCompile, tIntegrate, tComponentSplitter, and tMerge. Editing the source file and compiling it individually bypasses that pipeline entirely.

The compile succeeds. The deployment does not happen. The change is technically correct and completely invisible to the running system. The platform is not broken. It is just not looking at the file you changed. It is like shouting instructions at someone who is wearing noise-cancelling headphones. Your instructions are perfectly clear. They are simply not being received.

A simple decision rule

Before you open a tool, ask one question:

A routine is a .b file that contains processing logic. It is called by other routines, enquiries, or batch processes. It does not define the structure of a T24 component. Routines are safe to compile withjbc. Think of it as a simple tool for a simple job, like a screwdriver. You do not need a full workshop to turn one screw.

A framework object is a version, enquiry, browser component, or any other artifact that T24 manages through its component model. These objects need the Design Studio build pipeline to be packaged correctly for runtime use. Think of it as the difference between changing a lightbulb and rewiring the entire building. Both involve electricity. One requires considerably more planning.

If you are unsure which category your change falls into, assume it is a framework object until proven otherwise. That assumption will save you more time than it costs. The Design Studio pipeline will tell you if the object does not need it. The reverse is not true — jbc will compile almost anything and tell you nothing about whether the result will be picked up at runtime. It is the most agreeable compiler you will ever meet. It will say yes to everything and leave you to discover the truth on your own, usually at 2am during a production incident.

The wider pattern

This confusion is not really about two tools. It is about a shift in how TAFJ manages code compared to TAFC. It is the difference between living in a village where everyone knows everyone and moving to a city where you need forms in triplicate just to change your address.

TAFC was simpler because it was less structured. You could edit almost anything with a text editor and the change was live. That simplicity came at a cost: no clear separation between routine logic and framework configuration, no formal deployment pipeline, and no reliable way to track what was actually running in production. It worked until it did not, and when it did not, you had to guess. It was the software equivalent of a Vogon constructor fleet — it got the job done, but nobody wanted to look too closely at how.

TAFJ introduces structure that looks like overhead until you need to understand why a change did not take effect, or roll back a bad deployment, or reproduce a production configuration in a lower environment. At that point, the structure is not overhead. It is the thing that makes those operations possible. The overhead is the feature. It is the paperwork that saves you from demolishing the wrong building.

The practical takeaway is not about memorising which tool to use for which file type. It is about recognising that TAFJ has a deployment model, and that model applies to framework objects whether you use it or not. The choice is not between jbc and Design Studio. The choice is between following the deployment model and wondering why your changes disappeared. It is the difference between reading the instructions and discovering that the instructions were, in fact, quite important.

Practical takeaway

When working in TAFJ, the right question before touching a compile or build tool is not "which tool is installed?" but "what kind of artifact am I changing?"

• A standalone routine uses jbc.
• A framework-managed object uses Design Studio.

Mixing those up produces the most frustrating kind of TAFJ defect: the one where everything looks correct and nothing works. It is the software equivalent of a fire alarm that only goes off when there is no fire, and stays silent when the building is actually burning down. If you are not sure which category your change falls into, start with Design Studio. The build pipeline will tell you if the object does not need it. The reverse is not true — jbc will compile almost anything and tell you nothing about whether the result will be picked up at runtime. It is the most agreeable compiler you will ever meet. It will say yes to everything and leave you to discover the truth on your own. And it will do so with a pleasant, unhelpful smile.