v0.12.1

Compare Source

This release contains hotfixes for release 0.12.0

• Fix the default output dir for tests when running from Gradle
• Fix the issue with the translation of try/catch statements in WebAssembly GC
• Fix setting debug info location via Gradle plugin DSL
• Fix setting NIO buffer position after relative bulk transfer
• Fix issue in ZipFile implementation, see #​954
• Fix error stack traces not reported properly in out-of-process mode
• When devirtualizing during inlining, check that the target method is not abstract

v0.12.0

Compare Source

The main driver for this release was making WebAssembly GC backend on par with JavaScript backend. Now, only one feature of the JavaScript backend is not supported in Wasm GC: threading. This will be addressed in future releases.

Here's the list of improvements to the backend:

1. Reflection support. It's far from being full, but now all features, supported in JavaScript, are also supported in WebAssembly GC.
2. Improved generation of virtual tables. Little optimization techniques were implemented to reduce the size of virtual tables generated for large projects.
3. Reduced size of overhead, produced for various types of arrays. Actually, there's no more overhead: all object array types share the same code. This can cause insignificant performance loss in favour of a significantly smaller binary size in large projects.
4. JS string builtins proposal is now used when available (for now it's only unsupported in Safari), which significantly improves string interchange between Java and native JS APIs.

Another big change worth mentioning is the refactoring of NIO buffers. It was also driven mostly by the need of JS interop in Wasm GC backend, but as a result, all other backends benefit from this improvement. While previously NIO buffers were backed by arrays, now each backend uses more appropriate implementation. This includes typed arrays in JavaScript BE and direct memory addresses in C and old WebAssembly backends. Also, direct buffers in C are now allocated using malloc and using dedicated allocator in Wasm GC, that uses Wasm memory.

The latter change allows overcoming one major limitation of WebAssembly GC proposal: the inability to represent WebAssebmly array type as a JavaScript typed array. WebAssembly memory can be represented directly as a JavaScript typed array. So the solution is to allocate direct buffers over WebAssembly memory and then pass NIO buffers directly to JavaScript without any copying. In this regard JSO now allows passing NIO buffers directly to JavaScript. In this case they will be seen as a type array or as an ArrayBufferView respectively.

When this is not an option, though, and JS interop needs to fall back to copying data between arrays, it's now done via WebAssembly memory. Although one extra copy needs to be performed, the overall performance is times better than copying through WebAssebmly/JS barrier.

To make code re-usable between JavaScript and WebAssembly while still benefiting from the ability to pass data without copying, @JSByRef annotation gets optional parameter. "Optional by-ref" means that any backend that supports it (namely, JavaScript) passes data by reference, while others (WebAssembly GC) copies data.

Special thanks to libGDX project and personally to @​xpenatan for testing WebAssembly GC backend with their TeaVM backend, which gave the opportunity to find and fix some bugs. Also, thanks to contributors:

• @​Ihromant
• @​tryone144
• @​scf37
• @​vonZeppelin

Finally, a big thank you to @​reportmill and @​shannah
for sponsoring the project as well as other sponsors (see full list).
You can join these people and start supporting the project.

v0.11.0

New WebAssembly backend

This release is mostly driven by development of new WebAssembly backend. Old WebAssembly backend exists for many years and works well, however, did not see any adoption. The main reason is that it does not add significant advantages (like performance improvements), but makes development experience much worse, i.e. does not allow to easily interact with browser JS APIs and produces large binary files (times as large as JS).

With introduction of new WebAssembly GC proposal these problems were solved. However, this is not just small addition to original WebAssembly spec, but a game changer, it was impossible just to improve existing backend to support new proposal. So the decision was made to create a brand new WebAssembly backend, which would co-exist with the old one. Perhaps, at some point old WebAssembly backend will be deprecated and fully removed, but for now they will co-exist. However, WebAssembly GC will be advertised as primary WebAssembly target and the documentation will be maintained for WebAssembly GC, not for old WebAssembly.

New WebAssembly GC is a bit limited compared to JS backend, but mostly provides all features available in old WebAssembly backend. Moreover, WebAssembly GC fully supports JSO, as Java-to-JS interaction API. Hopefully, the next release will cover remaining features and WebAssembly GC backend will be on par with JS backend and the "experimental" tag will be removed from WebAssembly support.

Java class library emulation

• Fixed bugs in BitSet implementation
• Add ceilDiv, ceilDivExact, ceilMod, floorDivExact, absExact to Math class.

Support for JS APIs

• Reading files from <input type="file">, which includes classes like File, Blob, ReadableStream and so on.
• Binding for HTMLElement.touch and HTMLElement.input events.
• Binding for Popover API.
• Binding for Navigator.sendBeacon
• Binding for Error.cause

Other stuff

• Long emulation was removed from JS runtime. Now JS only relies on BigInt, which is supported by all browsers for more than 4 years.

Sponsorship

Worth mentioning that TeaVM evolved with the support from its sponsors. If you like this project, you can start donating.

Special thanks to @​reportmill and @​shannah, our permanent sponsors!

Contributors

• @​lax1dude
• @​Ihromant
• @​hontvari
• @​lasse-cs
• @​pizzadox9999
• @​SquidDev

Special thanks to @​Ihromant, @​lax1dude and xpenatan, who were early adopters of WebAssembly GC backend and helped to find some bugs there. Also, I want to highlight @​lax1dude, who not only enabled WebAssembly GC in his project, bug managed to identify, fix and successfully sent his PR to main repository.