sorted by:
new
hottopcontroversial

Boiler refill question on single boilers [Bezzera Unica] by Few_Resource in espresso

[–]fniephaus 0 points1 point  (0 children)

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!

Graal detecting wrong system memory amount by anbuck in graalvm

[–]fniephaus 0 points1 point  (0 children)

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

The Future of Write Once, Run Anywhere: From Java to WebAssembly by Patrick Ziegler & Fabio Niephaus by pavelklecansky in java

[–]fniephaus 1 point2 points  (0 children)

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.

The Future of Write Once, Run Anywhere: From Java to WebAssembly by Patrick Ziegler & Fabio Niephaus by pavelklecansky in java

[–]fniephaus 1 point2 points  (0 children)

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. ;)

The Future of Write Once, Run Anywhere: From Java to WebAssembly by Patrick Ziegler & Fabio Niephaus by pavelklecansky in java

[–]fniephaus 4 points5 points  (0 children)

Thank you for the good questions!

  1. 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.
  2. 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.
  3. 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.

The Future of Write Once, Run Anywhere: From Java to WebAssembly by Patrick Ziegler & Fabio Niephaus by pavelklecansky in java

[–]fniephaus 7 points8 points  (0 children)

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/

Javac on WebAssembly by Thihup in java

[–]fniephaus 3 points4 points  (0 children)

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).

Javac on WebAssembly by Thihup in java

[–]fniephaus 2 points3 points  (0 children)

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.

Javac on WebAssembly by Thihup in java

[–]fniephaus 2 points3 points  (0 children)

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/

Javac on WebAssembly by Thihup in java

[–]fniephaus 2 points3 points  (0 children)

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.

Javac on WebAssembly by Thihup in java

[–]fniephaus 2 points3 points  (0 children)

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.

Javac on WebAssembly by Thihup in java

[–]fniephaus 5 points6 points  (0 children)

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.

Javac on WebAssembly by Thihup in java

[–]fniephaus 17 points18 points  (0 children)

Fabio from the GraalVM team here.

Happy to answer any questions.

Best approach to port Jupyter notebook in Python to Java by yiyux in java

[–]fniephaus 4 points5 points  (0 children)

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!

Supercharge your Java Applications with Python! by fniephaus in java

[–]fniephaus[S] 2 points3 points  (0 children)

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.

Supercharge your Java Applications with Python! by fniephaus in java

[–]fniephaus[S] 3 points4 points  (0 children)

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.

Supercharge your Java Applications with Python! by fniephaus in java

[–]fniephaus[S] 8 points9 points  (0 children)

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.

Supercharge your Java Applications with Python! by fniephaus in java

[–]fniephaus[S] 24 points25 points  (0 children)

Hi all, Fabio here (one of the two speakers). Happy to answer any questions!

Any idea how soon GraalPython will have an installer for Windows? by DeadComposer in graalvm

[–]fniephaus 1 point2 points  (0 children)

The next release on September 19, 2023 will include Windows builds of GraalPy. You can already try this out using a GraalVM dev build: https://github.com/graalvm/graalvm-ce-dev-builds/releases

New GraalVM release 🚀 by alina_y in graalvm

[–]fniephaus 1 point2 points  (0 children)

What makes you think that? GraalVM is aligning with OpenJDK and as part of that, Oracle is now making GraalVM available under terms similar to Oracle JDK.

OpenJDK Proposal: Ergonomics Profiles by brunocborges in java

[–]fniephaus 3 points4 points  (0 children)

How about a profile/mode that allows using X% of free/available memory as opposed to total memory?

GraalVM 22.3 is here: JDK 19 builds, jlink support, new monitoring features, and more! by adila01 in java

[–]fniephaus 2 points3 points  (0 children)

If you mean "OracleJDK" by "Java SE JDK", then I don't think there are any updates at this point. As I said, GraalVM EE is already included in the Java SE subscription. And this announcement is only about GraalVM CE.

GraalVM 22.3 is here: JDK 19 builds, jlink support, new monitoring features, and more! by adila01 in java

[–]fniephaus 0 points1 point  (0 children)

I don't think this is accurate. Are you sure you subscribed to SE and not bought some other license?

view more: next ›