(Thank you, genuine question)
The whole JavaScript thing was just marketing. In 1995, Java was THE hottest thing so associating it with Java might fuel adoption/acception.
There is an old saying; Java is to JavaScript what Car is to to Carpet.
Re. your compiled question. It's up to the browser on how to execute JavaScript. E.g. Chrome has the V8 engine. This is the VM that compiles and executes JavaScript within Chrome. Other browsers might have different engines.
Java code has lots of structure required to write a minimal program. Java is transformed by compilation into a set of .class files. Then, in turn, a loader loads, resolves all the classes, and begins transforming and executing code.
These distinctions can be muddy sometimes.
The twist is that the JVM (Java Virtual Machine) is also a kind of interpreter, but can do on-the-spot ("just-in-time") compilation of parts of the code as well.
Java is great at what it does, which is not scripting.
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.
It's not like writing a basic cache is very hard...or just "borrow" one from an OS implementation.
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.