5 ms·

H2JVM – A Haskell Library for Writing JVM Bytecode

48 points by rowbin 4mo ago

J-Kuhn 4mo ago
At a quick glance, it seems to be missing some hook to resolve class hierarchies - which is needed when merging stacks with different types. Consider var foo = expr ? new Foo() : new Bar(); For such an expression, some superclass or superinterface for both Foo and Bar has to be chosen. What I am curios about is, if the java classfile API[1] provides a good model that could work in Haskell as well - I always had the impression that it was heavily influenced by functional programming, for example it uses "lifting transforms"[2]. PS: Good work on the label resolving part - this model is also used by the Java Classfile API and before it, ASM. [1]: https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/lang/classfile/package-summary.html https://docs.oracle.com/en/java/javase/26/docs/api/java.base... [2]: https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/lang/classfile/package-summary.html#lifting-transforms-heading https://docs.oracle.com/en/java/javase/26/docs/api/java.base...
amarant 4mo ago
This... Confuses me profoundly. My entire career I've worked with Java, and it's mostly a pretty decent language, imo. I think my biggest gripe with Java is the JVM. It's limiting, doesn't really provide any value(the proposed value is portability, but we always run apps in docker containers anyway, so what is it really doing for us?) I (kinda) get why someone might want to write Haskell rather than Java, but I'm just not sure why you would want to run Haskell on the JVM?
- vips7L 4mo ago
  An interesting take. You get lots of things for free when targeting JVM bytecode. GCs, JITs, interop with one of the largest and most battle tested ecosystems.
- rienbdj 4mo ago
  Pretty good performance for low effort is a big win.
- deleted 4mo ago
  [deleted]
- pron 4mo ago
  The reason most "serious" or important software is written for the JVM these days is because it gives you an unparalleled combination of performance, productivity, and observability. There's almost no competition if these things are what you need. The problem isn't so much why pick Java among the alternatives, but that there are hardly any alternatives.
  - AlotOfReading 4mo ago
    You have to put on some very narrow lenses to argue that "most" serious software is written for the JVM. Operating systems, compilers, browsers, databases, planes, cars, the transaction processing for at least one major payment processor, major cloud services, etc predominantly use other languages. I don't think there's any single language that most serious software is written in.
    - pron 4mo ago
      C, C++, and C# are obviously also major players in "serious software", but you can estimate the volume of software through the number of people involved (e.g. https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/ https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...). If Java doesn't have an outright majority, it has an obvious plurality. And again, there aren't many alternatives.
- tikhonj 4mo ago
  This project isn't for running Haskell on the JVM, it's for writing a compiler that produces JVM bytecode. You'd use it if you wanted to implement your own JVM language in Haskell or maybe if you wanted to have some kind of JVM-backed domain-specific language embedded in Haskell.
- cogman10 4mo ago
  Wow, I think I have almost the exact opposite opinion here. Java is an ok language, but what really makes it shine is the JVM. It's one of the fastest VMs out there and is one of the most customizable ones as well. For example, pretty much all other languages with a GC have just a GC and that's it. Java allows you to pick and choose your GC based on the workload. It is one of the least limiting VMs out there because any knob you might want to tune, can be tuned. It's a huge value add. I think the only part of the JVM that's not great is the fact that objects are bulky and the lack of value classes. Which ultimately means every struct like object you want can have a pretty hefty price in terms of memory. But otherwise, it's best in class basically for everything.
  - amarant 4mo ago
    I do agree that as far as VM's go, the JVM is not bad. I guess my recent fascination with rust is kinda shining through here, but I've begun questioning the need for any sort of VM: even the best ones add overhead, and since in practice we always deploy to a very specific environment anyway (when was the last time you deployed a non-dockerized jvm app?), why not just build native executables and skip the overhead? I dunno, I feel like I'm deploying a VM in a VM in a VM, and at some point they cost more than they taste.
    - cogman10 4mo ago
      > even the best ones add overhead Nope. Quite the opposite. You can precompile Java to a static runtime using the likes of Graal or even android. That actually makes these applications slower, not faster. Part of this comes down to the Java language design. For Java, there is a lot of dynamic dispatch involved. In rust terms, it's as if almost every parameter was a `Box<dyn Foo>`. In Java, it's pretty natural to have a method like `void foo(List<Bar> baz){}` which can be called by any concrete list type. In fact, compiled down, this actually looks like `void foo(List baz) {}` in the bytecode. The JVM is able to capture runtime information and realize "Oh, `foo` is always called with an `ArrayList`. And that `ArrayList` always emits a `Bar` element." That allows it to optimize and directly call the `ArrayList` methods rather than having to always do a "Ok, determine the type, look up the method table, call the method". Which is exactly what rust has to do with a `Box<dyn Foo>` signature. To do something similar with Rust you have to do a more complex PGO compilation. Now, don't get me wrong, rust is smart. That's why they've designed the language such that `foo: Box<dyn Foo>` just isn't as ergonomic as `foo: &Foo`. The language pushes you to use the concrete structs when possible and to avoid doing dynamic dispatch. It supports it, but it requires a lot more ritual.
internet_points 4mo ago
see also https://github.com/Frege/frege https://github.com/Frege/frege and https://github.com/mchav/froid https://github.com/mchav/froid (though both are kind of dead I guess?)
- J-Kuhn 4mo ago
  There is also Idris 2 for JVM (https://github.com/mmhelloworld/idris-jvm https://github.com/mmhelloworld/idris-jvm) Frege targets Java source code, which is then compiled by javac - the downside of that approach is you can not preserve the line numbers for debug information.

48 points by rowbin 4mo ago

At a quick glance, it seems to be missing some hook to resolve class hierarchies - which is needed when merging stacks with different types. Consider var foo = expr ? new Foo() : new Bar(); For such an expression, some superclass or superinterface for both Foo and Bar has to be chosen. What I am curios about is, if the java classfile API[1] provides a good model that could work in Haskell as well - I always had the impression that it was heavily influenced by functional programming, for example it uses "lifting transforms"[2]. PS: Good work on the label resolving part - this model is also used by the Java Classfile API and before it, ASM. [1]: https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/lang/classfile/package-summary.html https://docs.oracle.com/en/java/javase/26/docs/api/java.base... [2]: https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/lang/classfile/package-summary.html#lifting-transforms-heading https://docs.oracle.com/en/java/javase/26/docs/api/java.base...

amarant 4mo ago

This... Confuses me profoundly. My entire career I've worked with Java, and it's mostly a pretty decent language, imo. I think my biggest gripe with Java is the JVM. It's limiting, doesn't really provide any value(the proposed value is portability, but we always run apps in docker containers anyway, so what is it really doing for us?) I (kinda) get why someone might want to write Haskell rather than Java, but I'm just not sure why you would want to run Haskell on the JVM?

vips7L 4mo ago
An interesting take. You get lots of things for free when targeting JVM bytecode. GCs, JITs, interop with one of the largest and most battle tested ecosystems.
rienbdj 4mo ago
Pretty good performance for low effort is a big win.
deleted 4mo ago
[deleted]
pron 4mo ago
The reason most "serious" or important software is written for the JVM these days is because it gives you an unparalleled combination of performance, productivity, and observability. There's almost no competition if these things are what you need. The problem isn't so much why pick Java among the alternatives, but that there are hardly any alternatives.
- AlotOfReading 4mo ago
  You have to put on some very narrow lenses to argue that "most" serious software is written for the JVM. Operating systems, compilers, browsers, databases, planes, cars, the transaction processing for at least one major payment processor, major cloud services, etc predominantly use other languages. I don't think there's any single language that most serious software is written in.
  - pron 4mo ago
    C, C++, and C# are obviously also major players in "serious software", but you can estimate the volume of software through the number of people involved (e.g. https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/ https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...). If Java doesn't have an outright majority, it has an obvious plurality. And again, there aren't many alternatives.
tikhonj 4mo ago
This project isn't for running Haskell on the JVM, it's for writing a compiler that produces JVM bytecode. You'd use it if you wanted to implement your own JVM language in Haskell or maybe if you wanted to have some kind of JVM-backed domain-specific language embedded in Haskell.
cogman10 4mo ago
Wow, I think I have almost the exact opposite opinion here. Java is an ok language, but what really makes it shine is the JVM. It's one of the fastest VMs out there and is one of the most customizable ones as well. For example, pretty much all other languages with a GC have just a GC and that's it. Java allows you to pick and choose your GC based on the workload. It is one of the least limiting VMs out there because any knob you might want to tune, can be tuned. It's a huge value add. I think the only part of the JVM that's not great is the fact that objects are bulky and the lack of value classes. Which ultimately means every struct like object you want can have a pretty hefty price in terms of memory. But otherwise, it's best in class basically for everything.
- amarant 4mo ago
  I do agree that as far as VM's go, the JVM is not bad. I guess my recent fascination with rust is kinda shining through here, but I've begun questioning the need for any sort of VM: even the best ones add overhead, and since in practice we always deploy to a very specific environment anyway (when was the last time you deployed a non-dockerized jvm app?), why not just build native executables and skip the overhead? I dunno, I feel like I'm deploying a VM in a VM in a VM, and at some point they cost more than they taste.
  - cogman10 4mo ago
    > even the best ones add overhead Nope. Quite the opposite. You can precompile Java to a static runtime using the likes of Graal or even android. That actually makes these applications slower, not faster. Part of this comes down to the Java language design. For Java, there is a lot of dynamic dispatch involved. In rust terms, it's as if almost every parameter was a `Box<dyn Foo>`. In Java, it's pretty natural to have a method like `void foo(List<Bar> baz){}` which can be called by any concrete list type. In fact, compiled down, this actually looks like `void foo(List baz) {}` in the bytecode. The JVM is able to capture runtime information and realize "Oh, `foo` is always called with an `ArrayList`. And that `ArrayList` always emits a `Bar` element." That allows it to optimize and directly call the `ArrayList` methods rather than having to always do a "Ok, determine the type, look up the method table, call the method". Which is exactly what rust has to do with a `Box<dyn Foo>` signature. To do something similar with Rust you have to do a more complex PGO compilation. Now, don't get me wrong, rust is smart. That's why they've designed the language such that `foo: Box<dyn Foo>` just isn't as ergonomic as `foo: &Foo`. The language pushes you to use the concrete structs when possible and to avoid doing dynamic dispatch. It supports it, but it requires a lot more ritual.

internet_points 4mo ago

see also https://github.com/Frege/frege https://github.com/Frege/frege and https://github.com/mchav/froid https://github.com/mchav/froid (though both are kind of dead I guess?)

J-Kuhn 4mo ago
There is also Idris 2 for JVM (https://github.com/mmhelloworld/idris-jvm https://github.com/mmhelloworld/idris-jvm) Frege targets Java source code, which is then compiled by javac - the downside of that approach is you can not preserve the line numbers for debug information.