41–50 of 50 posts
Earlier quoted context omitted.
on x86 and arm. not on s390.
In a Java Virtual Machine, it is a 32-bit signed value: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.ht...
apologies.
It really was nice and simple back then! I always chuckle when i come across this class, which has been there since the beginning, and does absolutely nothing: https://github.com/ufuu/JDK10/blob/main/src/src/java/lang/Co...
What do you mean by "does absolutely nothing"? It does something, namely load a dynamic library that presumably implements its methods. Now maybe that library has never done anything, but that's impossible to tell from the code you linked.
The early versions of the JVM didn't include a compiler, they were purely interpreting, so those calls had to be no-ops. Later versions included a JIT, but the decision of which classes and methods to compile was made by the JVM, and again, those calls were no-ops. As far as i know, there was never a JVM from Sun / Oracle where those methods did anything.
It's possible that IBM's or some of the other JVMs did something with those calls. But in general, having user code be involved in the decision of which methods to JIT is the wrong approach.
I vaguely remember that in the 1.0 era, the plan was that JIT compilers would be third-party plug-ins to the Sun JVM. So you'd buy a compiler from, say, Borland, install it into your JVM installation, and then when java.lang.Compiler was used, it would load your shiny new Borland compiler, which would somehow magically interact with the JVM to compile bytecode. I never heard of this happening. There wasn't a published JVM API for the compiler to talk to, so it would have required a lot of close cooperation between Sun and the compiler vendor.
https://github.com/ufuu/JDK10/blob/main/src/src/java/util/Da... > private int tm_year; /* years since 1900 */ when you have 4.3 billion years to choose from but decide for 1900.
Think about it.
In the 20th century, we commonly expressed the year by its last two digits, you know this is why we talk about "70s", "80s", "90s". It's a small number, not ambiguous, and it also happens to be "the number of years since 1900". So of course a computer in the mid to late 20th century would choose this base. IT means the number is convenient for display, but also works for the machine, because "years base 1900" is a valid machine model as well. And it became a popular time format others picked up.
Lo and behold, though, the world didn't end in 2000. What do we do? Well, let it go over 99 and we add "1900" to it for display purposes, so we can maintain BC.
There. That's why we didn't choose any other base from 4.3 billion years or whatever.
I remember being very excited when this came out. What impressed me right off was the java.net package -- back then, few language environments (except in Unix-land) had built-in networking support. That was usually a (kludgy) add-on package. That, along with Threads made Java really stand out as the language for the era of distributed computing. Applets were a great idea that unfortunately didn't pan out. It still ha…