Standard JVM, slightly smaller, much faster. This is comparing to Java 1.2 before JIT/Hotspot and a decade of performance work. (Also I doubt anyone had 7.7 years of experience with Java in 2000, so that would be general)
If we consider JavaCard or Java ME a java dialect then yes, it has gotten a lot smaller! I think neither of these where available in 2000.
Running Java also does not need a JVM. There are AOT compilers for JAVA. Like Lisp there are a lot of different implementations with lots of differing trade offs.
In any case a very flawed comparison, like all programming languages comparison of this kind as it is so hard/expensive to do it correct.
But an interesting read anyway.
I think of languages as equivalent (they are all turing complete right) so something buildable in one must be buildable in the other. The question is what tradeoffs do the languages make for the humans in the loop.
Lisp and Java make different tradeoffs there, and C makes yet another set of tradeoffs. And which languages we use is more often dependant on historical accidents than technical excellence (like most human languages) see JS as an example.
I believe dynamic languages are better for small teams and short project life times. I believe automatic memory management by default languages are better for the vast majority of projects than manual memory management options.
I think a written language like Traditional Chinese (Java) is better for running an empire than one like Latin (Lisp). But a more modern idea like Hangul (Clojure?) might do even better.
In the end to get the best CPU performance one needs to know the CPU and architecture as well as an ability to think in bits. And like in human language one can write poetry in all of them, its just a bit more difficult than the office memo's we tend to write and read in our jobs ;)
If we consider JavaCard or Java ME a java dialect then yes, it has gotten a lot smaller! I think neither of these where available in 2000.
Running Java also does not need a JVM. There are AOT compilers for JAVA. Like Lisp there are a lot of different implementations with lots of differing trade offs.
In any case a very flawed comparison, like all programming languages comparison of this kind as it is so hard/expensive to do it correct.
But an interesting read anyway.
I think of languages as equivalent (they are all turing complete right) so something buildable in one must be buildable in the other. The question is what tradeoffs do the languages make for the humans in the loop.
Lisp and Java make different tradeoffs there, and C makes yet another set of tradeoffs. And which languages we use is more often dependant on historical accidents than technical excellence (like most human languages) see JS as an example.
I believe dynamic languages are better for small teams and short project life times. I believe automatic memory management by default languages are better for the vast majority of projects than manual memory management options. I think a written language like Traditional Chinese (Java) is better for running an empire than one like Latin (Lisp). But a more modern idea like Hangul (Clojure?) might do even better.
In the end to get the best CPU performance one needs to know the CPU and architecture as well as an ability to think in bits. And like in human language one can write poetry in all of them, its just a bit more difficult than the office memo's we tend to write and read in our jobs ;)