Class files contain compiled bytecode, not source code like shell scripts do. “Script” implies human-readable source code. Java bytecode is binary, a kind of portable machine language.
back
2 comments
Of course, there's murky things like Python which make bytecode compiled forms behind the scene.
But there's a lot of magic involved in transforming Java to class files, and then there's a lot of further magic in resolving, loading, and eventually executing classes.
PHP does the same. It’s compiled to a bytecode before execution. But I don’t think it’s cached anywhere like Python (but that may have changed in the decade since I’ve used it)
PHP has had an OPCache as an add-on since 5.1.0(around 2004), and by default since 5.5.0: https://www.php.net/manual/en/intro.opcache.php
It better be cached or else that would be a total tradegy... why wouldn't you automatically want to cache the prerendered pages whenever possible?
It's not like writing a basic cache is very hard...or just "borrow" one from an OS implementation.
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.
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.
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.
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”.
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...