[hi41]

Does this mean java .class falls in the middle of scripts and native executables? Is this analogy correct? For example, I think of native executable as Microsoft Word where you can doubleclick and launch it. Whereas with .class you have to run it on top of a jvm.

[pwdisswordfish4]

No. If you must insist on thinking of them as distinct from native executables, then consider them foreign executable instead—object files written for a different machine architecture and a different loader convention. There's really no middle ground they're occupying.

[mlyle]

This is a very good way to put it.

The super pedant in me, of course, would say they're a sliver in the middle because they're targeted at running in a software-implemented VM instead of on a real machine architecture, and that this isn't all that different from in-memory interpreter bytecode or something like a .pyc written to disk...

But then something like the more complicated loaders for native executables is a sliver in the middle, too. And then you look at something like the AS/400 with super-high level "instructions" and these distinctions get super, super muddy.

[layer8]

Not exactly. For one, class files are just components of a program, so more akin to .o or .so files, not executables. That set aside, they are binaries for a virtual machine, the JVM. One difference to real machines is that the bytecode doesn’t have access to untyped memory and to the hardware (not even “virtual” hardware), and some instructions have more complex semantics than you usually have in real hardware, but otherwise it’s not so much different from actual machine code. Overall it’s closer to native than to script, and therefore I wouldn’t quite say that it’s in the “middle”.

[mlyle]

Often even a "native" executable is opened by something like the ELF interpreter, relocated, etc. Yes, a JVM is a lot more heavyweight than these services, but...