5 ms·

This is cool. Not because it's useful or performant etc. but because it shows how simple java bytecode is. After seeing this I wanted to know: - how many opco

by brad0 9y ago

This is cool. Not because it's useful or performant etc. but because it shows how simple java bytecode is. After seeing this I wanted to know: - how many opcodes exist in the JVM - how easy would it be to create another language that compiles to the JVM. - how does the JVM represent basic data types The list goes on. All because someone built a JVM in JS. What happened to the hacker mentality of HN? Where's the curiosity gone?

tathougies 9y ago
People have written x86 emulators in javascript. That doesn't make x86 bytecode simple.
winter_blue 9y ago
This. I don't think enough people appreciate how the simple and clear the JVM byte code's design is. Most platforms in use today are so complex. Take a look at x86, or one of the latest ECMAScript specifications. Even LLVM bitcode is a bit complicated compared to the JVM bytecode. I think in programming language research, going forward, we need some research into "high-level bytecodes". I.e. bytecodes that capture high-level concepts in a clear and simple way.
- jdmichal 9y ago
  I've actually found CIL to be simpler than JVM bytecode, even with additional capabilities. Simple addition is a good example: JVM: dadd, fadd, iadd, ladd. Addition for double, float, int, and long data, respectively. CIL: add, add.ovf, add.ovf.un. Addition, signed addition with overflow check, and unsigned addition with overflow check.
  - kodfodrasz 9y ago
    I also prefer the CIL and also the C# language to Java (though I really like Java and its ecosystem), but we have to admit that MS had 5-10 years to learn from the Java design decisions and their effects, and still did not manage to overcome every problematic point :)
    - pjmlp 9y ago
      They also had difference purposes driving their design, and we should not forget that. JVM - Bytecodes only for Java CIL - Bytecodes for VB.NET, C#, Managed C++ and the 1.0 SDK contained examples for Lisp, Pascal, Eiffel, Ada, .... Of course, history then took another path for the JVM. EDIT: Forgot that C++/CLI replaced Managed C++, which was the C++ variant on 1.0.
      - shellac 9y ago
        > JVM - Bytecodes only for Java Although it should be mentioned that java language semantics are largely (depending on how you measure them :-) absent from the jvm. (Default methods were a very unusual change in that respect) And, as you say, subsequent history has weirdly inverted the JVM and CIL. The former is a lot less 'J' and the latter is a lot less 'C' ;-)
        cwyers 9y ago
        I would bet that there's a lot higher rate of .NET users running VB.NET than there are JVM users running Scala/Clojure/Kotlin. They just don't tend to be the sort to post to Hacker News.
        readittwice 9y ago
        Although this might really be true, I am skeptical that this has something to do with the inherent design of the Java bytecode compared to the CIL.
        shellac 9y ago
        But there are probably more CPUs running non-java JVM languages ;-) It all depends what you count, as usual. (I was really referring to the healthy non-java jvm language community. JRuby, Scala, and Clojure have lively communities and commercial backing)
  - bad_user 9y ago
    Those bytecodes happened because the JVM bytecode was designed to be easily interpreted, whereas CIL was designed for JIT compilation. So for example CIL's `add` opcode is missing info that needs to come from the context in which it is used and the JVM's `iadd` and variations are easier to interpret. You can see this design choice even today in how the JVM and CLR work. The JVM starts execution in an interpreter mode, then gradually compiles pieces of code as it detects bottlenecks. So the compilation that happens at runtime is very gradual and based on runtime measurements. The CLR on the other hand has done JIT compilation, with the ability to cache the compiled code for faster startup (e.g. Ngen). So it has been oriented towards ahead of time compilation. Different trade-offs.
    - jdmichal 9y ago
      Sure. I tried to find information yesterday when I posted that regarding whether / how the `add` code handles differing types. Now since I'm not on my phone, I looked up the ECMA spec and it looks like CIL still only allows like types, with some minor exceptions involving `native int`. So it's just up to the compiler to make sure that actually happens and extend types as necessary.
- _pmf_ 9y ago
  I think the bane of James Gosling's existence is being incorrectly associated with Java-the-lacklustre-language instead of correctly being associated with the superb JVM.
  - jhbadger 9y ago
    Personally, I always associate him with a pre-GNU version of Emacs: https://en.wikipedia.org/wiki/Gosling_Emacs https://en.wikipedia.org/wiki/Gosling_Emacs
- readittwice 9y ago
  If there is a problem with java bytecode, then that is hard to verify. You need multiple passes over the bytecode, until you've reached a steady state. There is also the "issue" that Java bytecode allows arbitrary control flows with goto, while Java doesn't. IMHO WebAssembly solves that better but I also need to admit that they could already learn from Java.
  - kodablah 9y ago
    > IMHO WebAssembly solves that better but I also need to admit that they could already learn from Java. While that may be true of the language Java, WebAssembly's jump instructions are not without their annoyances too. For example, the JVM bytecode requires your stack to be precise when jumping, WebAssembly just cares about the most recent piece. If you expect your jump targets to have the same stack layout, WebAssembly makes the impl handle it. I had to account for this and other differences in my compiler [0]. 0 - https://github.com/cretz/asmble#control-flow-operations https://github.com/cretz/asmble#control-flow-operations
mintplant 9y ago
Back when Java decompilers were much more primitive and easy-to-break than they are now, I wrote some mods for a Java game in a language called "Jade", which was essentially a textual syntax for raw JVM bytecode. Oddly enough I can't easily find any references to this tool online now.
- dboreham 9y ago
  Beyond the Internet Event Horizon :(
  - codefined 9y ago
    Overtaken by HTML templating languages, gems and a dozen other things with the same name. Eventually these items reach such a density to form a black hole, sucking through the older items, perhaps to another place in spacetime.
- bcg1 9y ago
  Are you sure it wasn't Jasmin? http://jasmin.sourceforge.net/ http://jasmin.sourceforge.net/
  - mintplant 9y ago
    Aha, you're right! Thanks.
- gergoerdi 9y ago
  I've used Krakatau, a JVM assembler / disassembler written in Python, to good effect in a project: https://github.com/Storyyeller/Krakatau https://github.com/Storyyeller/Krakatau
valarauca1 9y ago
Here ya go. Java's internals are super well documented/specified Loader stuff: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht... Byte Code is simple: https://en.m.wikipedia.org/wiki/Java_bytecode_instruction_listings https://en.m.wikipedia.org/wiki/Java_bytecode_instruction_li...
- guelo 9y ago
  Doesn't look that simple.
  - valarauca1 9y ago
    Ah friendo you've never read x64 assembly
electrum 9y ago
The JVM has a full specification: https://docs.oracle.com/javase/specs/jvms/se8/html/ https://docs.oracle.com/javase/specs/jvms/se8/html/ The specification is dense but still readable. I'd start reading in order, up through the third chapter which explains how to compile various Java snippets to bytecode. Perhaps start there and go back to the second chapter when you need more context. I've also found this old but still relevant book to be a good guide: http://www.artima.com/insidejvm/ed2/ http://www.artima.com/insidejvm/ed2/
dangisafascist 9y ago
Hackers solve challenging problems whose solutions are not clear. This is not a challenging problem, and the solution was obvious. This is not an example of curiosity being explored.

by brad0 9y ago

tathougies 9y ago

People have written x86 emulators in javascript. That doesn't make x86 bytecode simple.

winter_blue 9y ago

This. I don't think enough people appreciate how the simple and clear the JVM byte code's design is. Most platforms in use today are so complex. Take a look at x86, or one of the latest ECMAScript specifications. Even LLVM bitcode is a bit complicated compared to the JVM bytecode. I think in programming language research, going forward, we need some research into "high-level bytecodes". I.e. bytecodes that capture high-level concepts in a clear and simple way.

jdmichal 9y ago
I've actually found CIL to be simpler than JVM bytecode, even with additional capabilities. Simple addition is a good example: JVM: dadd, fadd, iadd, ladd. Addition for double, float, int, and long data, respectively. CIL: add, add.ovf, add.ovf.un. Addition, signed addition with overflow check, and unsigned addition with overflow check.
- kodfodrasz 9y ago
  I also prefer the CIL and also the C# language to Java (though I really like Java and its ecosystem), but we have to admit that MS had 5-10 years to learn from the Java design decisions and their effects, and still did not manage to overcome every problematic point :)
  - pjmlp 9y ago
    They also had difference purposes driving their design, and we should not forget that. JVM - Bytecodes only for Java CIL - Bytecodes for VB.NET, C#, Managed C++ and the 1.0 SDK contained examples for Lisp, Pascal, Eiffel, Ada, .... Of course, history then took another path for the JVM. EDIT: Forgot that C++/CLI replaced Managed C++, which was the C++ variant on 1.0.
    - shellac 9y ago
      > JVM - Bytecodes only for Java Although it should be mentioned that java language semantics are largely (depending on how you measure them :-) absent from the jvm. (Default methods were a very unusual change in that respect) And, as you say, subsequent history has weirdly inverted the JVM and CIL. The former is a lot less 'J' and the latter is a lot less 'C' ;-)
      - cwyers 9y ago
        I would bet that there's a lot higher rate of .NET users running VB.NET than there are JVM users running Scala/Clojure/Kotlin. They just don't tend to be the sort to post to Hacker News.
        readittwice 9y ago
        Although this might really be true, I am skeptical that this has something to do with the inherent design of the Java bytecode compared to the CIL.
        shellac 9y ago
        But there are probably more CPUs running non-java JVM languages ;-) It all depends what you count, as usual. (I was really referring to the healthy non-java jvm language community. JRuby, Scala, and Clojure have lively communities and commercial backing)
- bad_user 9y ago
  Those bytecodes happened because the JVM bytecode was designed to be easily interpreted, whereas CIL was designed for JIT compilation. So for example CIL's `add` opcode is missing info that needs to come from the context in which it is used and the JVM's `iadd` and variations are easier to interpret. You can see this design choice even today in how the JVM and CLR work. The JVM starts execution in an interpreter mode, then gradually compiles pieces of code as it detects bottlenecks. So the compilation that happens at runtime is very gradual and based on runtime measurements. The CLR on the other hand has done JIT compilation, with the ability to cache the compiled code for faster startup (e.g. Ngen). So it has been oriented towards ahead of time compilation. Different trade-offs.
  - jdmichal 9y ago
    Sure. I tried to find information yesterday when I posted that regarding whether / how the `add` code handles differing types. Now since I'm not on my phone, I looked up the ECMA spec and it looks like CIL still only allows like types, with some minor exceptions involving `native int`. So it's just up to the compiler to make sure that actually happens and extend types as necessary.
_pmf_ 9y ago
I think the bane of James Gosling's existence is being incorrectly associated with Java-the-lacklustre-language instead of correctly being associated with the superb JVM.
- jhbadger 9y ago
  Personally, I always associate him with a pre-GNU version of Emacs: https://en.wikipedia.org/wiki/Gosling_Emacs https://en.wikipedia.org/wiki/Gosling_Emacs
readittwice 9y ago
If there is a problem with java bytecode, then that is hard to verify. You need multiple passes over the bytecode, until you've reached a steady state. There is also the "issue" that Java bytecode allows arbitrary control flows with goto, while Java doesn't. IMHO WebAssembly solves that better but I also need to admit that they could already learn from Java.
- kodablah 9y ago
  > IMHO WebAssembly solves that better but I also need to admit that they could already learn from Java. While that may be true of the language Java, WebAssembly's jump instructions are not without their annoyances too. For example, the JVM bytecode requires your stack to be precise when jumping, WebAssembly just cares about the most recent piece. If you expect your jump targets to have the same stack layout, WebAssembly makes the impl handle it. I had to account for this and other differences in my compiler [0]. 0 - https://github.com/cretz/asmble#control-flow-operations https://github.com/cretz/asmble#control-flow-operations

mintplant 9y ago

Back when Java decompilers were much more primitive and easy-to-break than they are now, I wrote some mods for a Java game in a language called "Jade", which was essentially a textual syntax for raw JVM bytecode. Oddly enough I can't easily find any references to this tool online now.

dboreham 9y ago
Beyond the Internet Event Horizon :(
- codefined 9y ago
  Overtaken by HTML templating languages, gems and a dozen other things with the same name. Eventually these items reach such a density to form a black hole, sucking through the older items, perhaps to another place in spacetime.
bcg1 9y ago
Are you sure it wasn't Jasmin? http://jasmin.sourceforge.net/ http://jasmin.sourceforge.net/
- mintplant 9y ago
  Aha, you're right! Thanks.
gergoerdi 9y ago
I've used Krakatau, a JVM assembler / disassembler written in Python, to good effect in a project: https://github.com/Storyyeller/Krakatau https://github.com/Storyyeller/Krakatau

valarauca1 9y ago

Here ya go. Java's internals are super well documented/specified Loader stuff: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht... Byte Code is simple: https://en.m.wikipedia.org/wiki/Java_bytecode_instruction_listings https://en.m.wikipedia.org/wiki/Java_bytecode_instruction_li...

guelo 9y ago
Doesn't look that simple.
- valarauca1 9y ago
  Ah friendo you've never read x64 assembly

electrum 9y ago

The JVM has a full specification: https://docs.oracle.com/javase/specs/jvms/se8/html/ https://docs.oracle.com/javase/specs/jvms/se8/html/ The specification is dense but still readable. I'd start reading in order, up through the third chapter which explains how to compile various Java snippets to bytecode. Perhaps start there and go back to the second chapter when you need more context. I've also found this old but still relevant book to be a good guide: http://www.artima.com/insidejvm/ed2/ http://www.artima.com/insidejvm/ed2/

dangisafascist 9y ago

Hackers solve challenging problems whose solutions are not clear. This is not a challenging problem, and the solution was obvious. This is not an example of curiosity being explored.