Bump teavm.version from 0.6.1 to 0.12.0 #445

dependabot · 2025-05-19T04:33:43Z

Bumps teavm.version from 0.6.1 to 0.12.0.
Updates org.teavm:teavm-classlib from 0.6.1 to 0.12.0

Release notes

Sourced from org.teavm:teavm-classlib's releases.

0.12.0

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:

Reflection support. It's far from being full, but now all features, supported in JavaScript, are also supported in WebAssembly GC.

Improved generation of virtual tables. Little optimization techniques were implemented to reduce the size of virtual tables generated for large projects.

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.

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.

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

... (truncated)

Commits

See full diff in compare view

Updates org.teavm:teavm-jso from 0.6.1 to 0.12.0

Release notes

Sourced from org.teavm:teavm-jso's releases.

0.12.0

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:

Reflection support. It's far from being full, but now all features, supported in JavaScript, are also supported in WebAssembly GC.

Improved generation of virtual tables. Little optimization techniques were implemented to reduce the size of virtual tables generated for large projects.

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.

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.

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

... (truncated)

Commits

See full diff in compare view

Updates org.teavm:teavm-jso-apis from 0.6.1 to 0.12.0

Release notes

Sourced from org.teavm:teavm-jso-apis's releases.

0.12.0

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:

Reflection support. It's far from being full, but now all features, supported in JavaScript, are also supported in WebAssembly GC.

Improved generation of virtual tables. Little optimization techniques were implemented to reduce the size of virtual tables generated for large projects.

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.

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.

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

... (truncated)

Commits

See full diff in compare view

Updates org.teavm:teavm-maven-plugin from 0.6.1 to 0.12.0

Release notes

Sourced from org.teavm:teavm-maven-plugin's releases.

0.12.0

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:

Reflection support. It's far from being full, but now all features, supported in JavaScript, are also supported in WebAssembly GC.

Improved generation of virtual tables. Little optimization techniques were implemented to reduce the size of virtual tables generated for large projects.

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.

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.

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

... (truncated)

Commits

See full diff in compare view

Updates org.teavm:teavm-tooling from 0.6.1 to 0.12.0

Release notes

Sourced from org.teavm:teavm-tooling's releases.

0.12.0

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:

Reflection support. It's far from being full, but now all features, supported in JavaScript, are also supported in WebAssembly GC.

Improved generation of virtual tables. Little optimization techniques were implemented to reduce the size of virtual tables generated for large projects.

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.

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.

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

... (truncated)

Commits

See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

Bumps `teavm.version` from 0.6.1 to 0.12.0. Updates `org.teavm:teavm-classlib` from 0.6.1 to 0.12.0 - [Release notes](https://github.com/konsoletyper/teavm/releases) - [Commits](https://github.com/konsoletyper/teavm/commits/0.12.0) Updates `org.teavm:teavm-jso` from 0.6.1 to 0.12.0 - [Release notes](https://github.com/konsoletyper/teavm/releases) - [Commits](https://github.com/konsoletyper/teavm/commits/0.12.0) Updates `org.teavm:teavm-jso-apis` from 0.6.1 to 0.12.0 - [Release notes](https://github.com/konsoletyper/teavm/releases) - [Commits](https://github.com/konsoletyper/teavm/commits/0.12.0) Updates `org.teavm:teavm-maven-plugin` from 0.6.1 to 0.12.0 - [Release notes](https://github.com/konsoletyper/teavm/releases) - [Commits](https://github.com/konsoletyper/teavm/commits/0.12.0) Updates `org.teavm:teavm-tooling` from 0.6.1 to 0.12.0 - [Release notes](https://github.com/konsoletyper/teavm/releases) - [Commits](https://github.com/konsoletyper/teavm/commits/0.12.0) --- updated-dependencies: - dependency-name: org.teavm:teavm-classlib dependency-version: 0.12.0 dependency-type: direct:production update-type: version-update:semver-minor - dependency-name: org.teavm:teavm-jso dependency-version: 0.12.0 dependency-type: direct:production update-type: version-update:semver-minor - dependency-name: org.teavm:teavm-jso-apis dependency-version: 0.12.0 dependency-type: direct:production update-type: version-update:semver-minor - dependency-name: org.teavm:teavm-maven-plugin dependency-version: 0.12.0 dependency-type: direct:production update-type: version-update:semver-minor - dependency-name: org.teavm:teavm-tooling dependency-version: 0.12.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>

dependabot bot added dependencies Pull requests that update a dependency file java Pull requests that update java code labels May 19, 2025

dependabot bot mentioned this pull request May 19, 2025

Bump teavm.version from 0.6.1 to 0.8.1 #420

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Bump teavm.version from 0.6.1 to 0.12.0 #445

Bump teavm.version from 0.6.1 to 0.12.0 #445

Uh oh!

dependabot bot commented on behalf of github May 19, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Bump teavm.version from 0.6.1 to 0.12.0 #445

Are you sure you want to change the base?

Bump teavm.version from 0.6.1 to 0.12.0 #445

Uh oh!

Conversation

dependabot bot commented on behalf of github May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

0.12.0

0.11.0

New WebAssembly backend

Java class library emulation

Support for JS APIs

0.12.0

0.11.0

New WebAssembly backend

Java class library emulation

Support for JS APIs

0.12.0

0.11.0

New WebAssembly backend

Java class library emulation

Support for JS APIs

0.12.0

0.11.0

New WebAssembly backend

Java class library emulation

Support for JS APIs

0.12.0

0.11.0

New WebAssembly backend

Java class library emulation

Support for JS APIs

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

dependabot bot commented on behalf of github May 19, 2025 •

edited

Loading