Code Artifacts Have Different Execution Targets

Learning Question

Why do different code artifacts have different execution targets?

A code artifact is shaped for a particular next reader. It cannot be understood correctly without knowing which layer is supposed to read it next.

The artifact itself is stored representation. Its execution target is the tool, runtime, loader, or machine layer that knows how to use that representation.

Common Artifact Targets

Different artifacts answer different “who reads this next?” questions:

Artifact	Next target	What that target can do
source file	compiler, interpreter, or runtime	parse language text and transform or execute it
object file	linker	combine code and symbols into a larger executable artifact
native executable	operating-system loader	create a process image and transfer control to program startup code
class file or bytecode	managed runtime	load, verify, interpret, compile, and execute inside a runtime process
script	interpreter or shell	read commands and perform runtime behavior inside an interpreter process

The same word “code” can appear in each row, but the next reader is different.

An Artifact Is Not Defined Only by Its File Extension

File names help, but the real question is the artifact contract.

A .c file is expected to contain C source. A .o file is expected to contain object code in a format understood by linkers on that platform. A .class file is expected to contain JVM class-file structure. A native executable is expected to satisfy the operating system’s executable format rules.

The file extension is only a hint. The actual artifact must match the format and rules expected by the next reader.

Why Execution Target Is the Better Question

Asking “is this executable?” is often too vague.

An object file contains machine code, but it is not usually a complete program that the operating system can load as a process.

A class file contains executable JVM bytecode, but the CPU does not execute it directly as a native process. A JVM process must load it and provide the runtime environment.

A script may be launchable, but the running process is an interpreter or shell using the script as input.

The better question is:

Executable by what?

That question forces the missing layer into view.

Same Source, Different Targets

The same source-level intention can be aimed at different targets depending on language and tooling.

One language may produce a native executable for the operating system loader. Another may produce bytecode for a virtual machine. Another may keep source as launch input to an interpreter.

Those choices change where behavior is created:

native executable -> OS loader -> process -> CPU instructions
bytecode -> runtime process -> runtime-managed execution
source script -> interpreter process -> interpreted behavior

None of these paths makes the stored artifact identical to the run.

Mental Model

For any code artifact, ask:

What kind of artifact is this?
What reader is it designed for?
What does that reader create next?
Where will runtime state live?

The execution target is the missing label that prevents source files, object files, executables, bytecode, and scripts from blurring together.