Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Endive: A JVM native WebAssembly runtime

github.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Endive: A JVM native WebAssembly runtime

#31

Post by apignotti »

panick21_ wrote: post #29
apignotti wrote: post #8

Shameless plug: we solved the opposite problem, running any Java application in the browser via WebAssembly: https://labs.leaningtech.com/blog/cheerpj-4.3 And yes, it does run Minecraft as well :-) https://browsercraft.cheerpj.com/

Mmhh should work for clojure as well then. I should try this.

I can confirm non-Java languages work as expected. I've personally tried Kotlin, and IIRC some user from the community reported Clojure to be working as well.

Consider joining our Discord for help: https://discord.leaningtech.com

Re: Endive: A JVM native WebAssembly runtime

#32

Post by tegmentum »

tegmentum wrote: post #17

Another Shameless plug: A common interface for webassembly engines, including Chicory, in Java https://github.com/tegmentum/webassembly4j

I wrote this for a number of reasons but oddly enough Java probably has the most options as far as runtimes go but the support is pretty fractured. The underlying runtime adapters add support for wasmtime and wamr as well. There are two JNI implementations for wasmtime but they are badly out of date and haven't been updated in years. There are a number of reasons you might want to use one runtime over another and this was supposed to unify them under a single interface and make swapping them out easy. It also allows you to easily compare the tradeoffs of various engines.

Re: Endive: A JVM native WebAssembly runtime

#34

Post by pjmlp »

martypitt wrote: post #20
syrusakbary wrote: post #10

This is a fork of Chicory, a bit more context of the relationship between the projects can be found here: https://github.com/dylibso/chicory/issues/1296

Any background / context around what the Chicory author means in this comment? > We'll consider merging in changes that make sense from Endive, but under the stewardship of the [Byte Code Alliance] I have very little faith in its future. My words mean nothing though having all but completely lost interest and use for WebAssembly. What's the background / history of Byte Code Alliance?

Not everyone is on board with CORBA but with WebAssembly, which is basically what the reboot of the component model is, so probably that.

The AssemblyScript folks have a similar opinion.

Re: Endive: A JVM native WebAssembly runtime

#35

Post by throawayonthe »

pjmlp wrote: post #34
martypitt wrote: post #20

Earlier quoted context omitted.

Any background / context around what the Chicory author means in this comment? > We'll consider merging in changes that make sense from Endive, but under the stewardship of the [Byte Code Alliance] I have very little faith in its future. My words mean nothing though having all but completely lost interest and use for WebAssembly. What's the background / history of Byte Code Alliance?

Not everyone is on board with CORBA but with WebAssembly, which is basically what the reboot of the component model is, so probably that. The AssemblyScript folks have a similar opinion.

[dead]

Re: Endive: A JVM native WebAssembly runtime

#36

Post by jon_richards »

apignotti wrote: post #28
____tom____ wrote: post #26

Earlier quoted context omitted.

But can it run Endive?

Not something I tried myself, but conceptually if it's Java it should work. CheerpJ Just-In-Time compiles Java bytecode at runtime, so it makes no difference if the classes come from JAR files or are dynamically generated.

How close are we to the birth and death of yavascript?

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: Endive: A JVM native WebAssembly runtime

#37

Post by bhelx »

pjmlp wrote: post #34
martypitt wrote: post #20

Earlier quoted context omitted.

Any background / context around what the Chicory author means in this comment? > We'll consider merging in changes that make sense from Endive, but under the stewardship of the [Byte Code Alliance] I have very little faith in its future. My words mean nothing though having all but completely lost interest and use for WebAssembly. What's the background / history of Byte Code Alliance?

Not everyone is on board with CORBA but with WebAssembly, which is basically what the reboot of the component model is, so probably that. The AssemblyScript folks have a similar opinion.

yeah that is roughly the concern, many runtimes didn't want to continue on past wasip1, mostly because of the component model.

Re: Endive: A JVM native WebAssembly runtime

#38

Post by bhelx »

exabrial wrote: post #14

Projects like this would be significantly funner and easier to make in Jdk25+(well technically 24+) because of the new Java classfile/bytecode API. It looks like Endive uses OW2 ASM, probably because this supports back to Jdk11. The new jdk API has a minimum target of Jdk17. OW2 ASM is significantly harder to use IMHO though. What got me into this is I just finished a major release of Petrify ( https://github.com/exa…

if i understand correctly, the new redline compiler doesn't have these limitations. it's not based on asm. (edit: but this hasn't been merged to mainline yet)

Re: Endive: A JVM native WebAssembly runtime

#39

Post by bhelx »

pjmlp wrote: post #18
phickey wrote: post #5

Lots of context for this project on the Bytecode Alliance blog: https://bytecodealliance.org/articles/endive-and-the-next-ch...

Ah, looks like they will be packaging a Rust runtime on top, not as interesting as I thought.

the "redline" compiler is cranelift which is written in rust, but i think it's being compiled to Wasm first then JVM bytecode so it still works zero dependency. not sure if that will continue to be the case.

Re: Endive: A JVM native WebAssembly runtime

#40

Post by bhelx »

jbaiter wrote: post #7
gavinray wrote: post #2

See also: https://www.graalvm.org/webassembly/docs/

Yeah, this was the first thing that came to mind, how does this compare to the Truffle WASM implementation. The Graal Polyglot API is pretty incredible, we've been using it for a JavaScript/Python plugin system in a JVM app, and it's been amazing.

Agree about Graal being really good. there are some different use cases for embedding wasm in an application. chicory / endive is not just for embedding another language. the main use case was always secure plugin-systems. but there are other use cases. also it's not controlled by Oracle and works well outside of their ecosystem, which i think some people value. this question came up a few times and were addressed in talks and blog articles:

https://github.com/dylibso/chicory#on-the-press

Post reply on HN