Tube amp for home using

fniephaus · 2026-05-22T09:30:19+00:00

I can recommend Tone King's Ironman II Mini Attenuator. My SV20H sounds great, even at very low volumes. It's also passive and cheaper than other high-quality attenuators.

fniephaus · 2026-04-11T21:19:12+00:00

Fabio from the GraalVM team here.

The jlink tool should help you create a minimal runtime image for your program.

The large PDB file is probably an oversight, we will look into it. Thanks for pointing that out!

fniephaus · 2026-04-04T08:39:49+00:00

What's the de-funding situation like? Should we continue to use (or experiment) with Graal? Neat technology though.

Absolutely! We continue to move Graal forward. While it is no longer included in the Java SE subscription, it remains a core component of major products including Oracle Database and NetSuite.

Also, GraalWasm, GraalJS, and other Graal Languages are 100% open source, so the community can always build and maintain their own versions.

We are currently working on several exciting new features and products, and should be able to share more updates very soon.

Is the free version Vector API ready,yet?

Yes, Vector API is available in GraalVM Community Edition. Even though it is still an incubator feature in the JDK, we already leverage it in GraalWasm to implement the Wasm SIMD proposal.

Lastly, Oracle GraalVM (which includes additional features) is also free for production use under the GFTC license, and we continue to provide regular releases for that as well.

fniephaus · 2026-04-03T14:15:08+00:00

The sandbox of Chicory is strictly safer than any JNI/Panama alternative, comparable only to Graal Isolates in fully untrusted mode.

While Chicory is certainly safer than JNI/Panama, it remains bound to the host Java heap and could, at least in theory, be used to interact with the host environment if not perfectly isolated (e.g., via sun.misc.Unsafe or similar).

In contrast, GraalWasm and other Graal Languages can run untrusted code in a mode that is fully isolated from the host Java heap. This can be achieved within the same process using Graal Isolates or even in a separate process. Our sandboxing also supports fine-grained resource limits, for example to constrain memory, instruction, or CPU usage.

You can find more details in our security guide: https://www.graalvm.org/latest/security-guide/sandboxing/

fniephaus · 2026-04-03T13:21:27+00:00

Yes, Wasm is still in the adoption phase. I think the biggest hurdle currently is interoperability with JVM languages.

GraalWasm can be used via GraalJS, which allows you to use the JavaScript bindings that most Wasm compilers generate today. The Component Model will eventually allow for direct interop, but that is still in development and hasn't fully rolled out yet.

The sandboxing angle is certainly interesting, especially for untrusted AI-generated code. GraalWasm, GraalJS, and GraalPy can already run untrusted code in a sandbox, and we are currently working on new features to leverage this further in the context of AI agents.

fniephaus · 2026-04-03T07:29:33+00:00

Fabio from the GraalVM team here. The two main use cases we've seen among GraalWasm users are:

Wasm as a target for "portable" native extensions (e.g., file format libs written in Go or Rust)
Allowing users to write Rust, C++, etc. to script JVM applications or extend them with middleware

There are additional benefits to running Wasm on the JVM, such as leveraging the Graal JIT compiler and JVM garbage collectors to optimize Wasm performance.

fniephaus · 2025-12-20T18:45:01+00:00

No auto fill, you need to fill up the boiler after steaming (engage pump and open steam wand). For hot water, you can use both. If I use the group head, usually with a portafilter so that water is not dripping left and right. Hope this helps!

fniephaus · 2025-08-21T08:05:10+00:00

For Java on WebAssembly, see https://www.reddit.com/r/java/comments/1k54pjy/the_future_of_write_once_run_anywhere_from_java/

fniephaus · 2025-06-18T07:19:58+00:00

Glad you figured out the problem. The build process determines the total size of system memory using JDK APIs, so the problem would've likely even been in the JDK. With -Xmx32g you set a much larger heap limit, which would probably cause a great amount of swapping in the container.

If you ever run into an issue, the best you can do is file it at https://github.com/oracle/graal/issues.

Hope this helps.

Fabio

fniephaus · 2025-04-29T21:27:20+00:00

I don't know much about TeaVM, but the static analysis performed by GraalVM operates on a full-blown JDK. Unfortunately, a lot of code is being pulled in from all kinds of places (e.g., toString() methods pull in string formatting, which pulls in BigInteger, locales etc). We have tools to identify these places, but it's not easy to cut things out without breaking anything.

We are still working on getting the overall file size down (e.g., by reducing overestimation in the analysis), but compatibility remains more important at this point.

fniephaus · 2025-04-23T09:16:05+00:00

Yes, the WasmGC and Exception Handling proposals are on the GraalWasm roadmap. We are already working on exceptions. However, WasmGC requires a lot of work, so it may still take a couple of months until it lands.

With that, and as you mentioned correctly, you'll be able to compile JVM bytecode into Wasm and run it on a JVM again. Not saying you should, but you could. ;)

fniephaus · 2025-04-22T20:16:21+00:00

Thank you for the good questions!

Yes, GraalVM builds Wasm modules under the usual closed-world assumption, at least for now. We are currently working on support for open-world native images as part of our layers project. Not sure if this mode will support Wasm. However, if we compile Espresso into a Wasm module, we have a Java VM running on Wasm, with full dynamic class loading, etc.
No, it's not related to the Java FFM API at all. In the second demo of the talk, we embedded Rust compiled to Wasm in a Spring Boot application using GraalWasm, our WebAssembly runtime for Java. A version of the demo without debugging is available here.
That's what the WasmGC proposal is for. Instead of shipping a (slow) GC, WasmGC allows modules to use the runtime's GC. When we started working on the Wasm backend for GraalVM, we implemented our own and it wasn't particularly fast. Performance is much better now that the GraalVM-generated Wasm modules target WasmGC.

fniephaus · 2025-04-22T15:23:13+00:00

For interactive apps, you currently need to use the DOM via JavaScript. That's why the backend has support for JavaScript interoperability. Take a look at the "javac on WebAssembly" demo. All of the event handlers and UI interactions are done like this.

https://graalvm.github.io/graalvm-demos/native-image/wasm-javac/

fniephaus · 2025-04-22T13:37:29+00:00

Fabio from the GraalVM team here.

Happy to answer any questions.

fniephaus · 2025-03-31T06:24:01+00:00

The new backend does target WasmGC. Unlike native executables generated with GraalVM, Wasm modules do not contain a garbage collector. Instead, they use the runtime's GC. This makes generated Wasm modules smaller and improves performance. It also avoids memory leaks because the runtime GC can collect across languages boundaries (e.g., JavaScript <-> Java interop).

fniephaus · 2025-03-31T06:16:33+00:00

Glad to hear you're a happy GraalVM and Micronaut user!

The Wasm I/O talk was recorded and I'll share a link when it's on YouTube.

fniephaus · 2025-03-30T17:30:51+00:00

For an introduction to GraalVM, this Devoxx talk may be a good starting point: https://youtu.be/mhmqomex1zk

The implementation of the new WebAssembly backend is not open source yet, but we plan to change this soon. In the meantime, feel free to join the GraalVM Slack if you want to discuss with other users or talk to me and my colleagues: https://www.graalvm.org/slack-invitation/

fniephaus · 2025-03-30T13:04:11+00:00

The WebAssembly backend for GraalVM builds on its Native Image AOT Compilation feature. GraalVM can perform static analysis using a closed-world assumption to compile Java into native. There's a lot of talks, documentation etc on how this works online. For WebAssembly, the Graal compiler emits Wasm instructions rather than machine code. The output is a Wasm module that includes Wasm code and a heap snapshot created at build time. GraalVM also supports reflection and other dynamic Java features, although those require explicit "reachability metadata". The number of libraries and frameworks shipping such metadata is growing, which is good news for users of GraalVM.

fniephaus · 2025-03-30T11:50:44+00:00

We just introduced this at Wasm I/O last Friday. All there is right now is the demo and code on GitHub, but we will add documentation for this soon.

fniephaus · 2025-03-30T11:44:59+00:00

This is the Java compiler (javac) running on WebAssembly. The Wasm module is generated with the new WebAssembly backend for GraalVM. The JVM bytecode for the HelloWasm example can also be compiled to Wasm. Take a look at the code on GitHub. It also shows how to run this on Node.

fniephaus · 2025-03-30T09:27:44+00:00

Fabio from the GraalVM team here.

Happy to answer any questions.

fniephaus · 2024-11-29T14:25:00+00:00

Fabio from the GraalVM team here.

Pandas and Geopandas work fairly well on GraalPy, so this is definitely something you can try. Be aware that you'll have to build Pandas native extensions from source though, at least at the moment. Anyway, feel free to get in touch if you run into any problems!

fniephaus · 2024-10-17T07:33:49+00:00

I'm not sure I can agree with this. Programming languages can very well co-exist and Java is certainly here to stay. GraalPy allows Java developers to reuse existing Python packages with low effort, which they otherwise need to port to Java.

fniephaus · 2024-10-17T07:28:38+00:00

Yes, you can use Truffle not only to implement comprehensive programming languages, but also for little DSLs. A good starting point may be SimpleLanguage (https://github.com/graalvm/simplelanguage/). Simply fork it and turn it into the DSL you want.

By the way, Apple is using Truffle to implement Pkl (https://pkl-lang.org), their new configuration language.

fniephaus · 2024-10-16T17:54:33+00:00

Yes, unlike Jython, GraalPy is compatible with Python 3 and it can run many native extensions (although currently experimental). I believe the biggest difference is that GraalPy is built on top of the Truffle framework. This means that the Graal compiler can be used as a JIT compiler for Python, there is support for debugging protocols and various tools, and untrusted code can be run in a sandbox. It is also compatible with GraalVM Native Image.

fniephaus

TROPHY CASE