What are the pointless/annoying features of Java bytecode left over from ancient times?

Question

Java

Does the Java bytecode standard contain some very ancient solutions left over from the birth of the language, which once seemed like a good idea to the developers of the virtual machine, but now looks like pettiness or, on the contrary, firing a cannon at sparrows? Or is it something that irritated from the very beginning, which still prevents efficient use of the bytecode resource and forces compilers to fence multi-level crutches, just to get around the problems of unsuccessful implementation?
This is not about the internal structure of the virtual machine, I am aware that since the birth of the language there have been a lot of changes, and not about new and old features of the language itself, which are still compiled into the same bytecode. The question is about the single-byte instructions themselves, which the virtual machine eats.
(For example, I mean something like the stubs of the Intel 8086 architecture, which are forced to inherit all modern x86-64 processors)

Answer 1

If you look at history, the JVM was created in 1996 as a platform for embedded technology. Refrigerators. Coffee makers. There was such a specification. And of course, the spec itself had restrictions that would allow the bytecode to be assembled even on very weak machines. Where there are few registers and little bit depth. And we have a stack machine (like the MK-60 calculator) in which there is basically no register addressing. Unlike .Net/clr platforms where there is a more modern adaptation to the processor. In general, if you go to write code that will be friendly to SSE / AVX registers, then nothing will come of it. At the JVM level, the maximum bit depth of an algebraic type is 64 bits (signed). This seems to me to be the strongest limitation. And it is not known when the spec will be expanded.