CheerpJ Support

[reportmill]

How about support for CheerpJ? It should be able to leverage a lot of the work that went into the TeaVM support.

[salmonb]

Could you clarify what kind of benefit you have in mind with CheerpJ support in addition to GWT and TeaVM?

From my perspective, GWT and TeaVM are primarily compile-to-web backends, whereas CheerpJ seems more oriented toward runtime compatibility for existing Java applications, so I’m curious which overlap or synergy you’re seeing.

Related question: does CheerpJ already support JavaFX directly?
If so, I’d like to better understand what you see as the added value of integrating CheerpJ via WebFX rather than running JavaFX applications on CheerpJ as-is.

Happy to explore this further if you can share your perspective.

[reportmill]

I use the CJDom project to map Java graphics calls to DOM/WebAPIs with my SnapKit UI library:

CJDom: https://github.com/reportmill/CJDom

It has most of the APIs for HTMLCanvasElement/CanvasRenderContext2D and WebGL (and many more).

[salmonb]

Ok so if I understand correctly, the idea would be to ensure WebFX compatibility by providing a CJDom-based runtime polyfill for Elemental2, right?

If that’s the case, the question becomes: where would that polyfill live and who would maintain it?
Would you see it as a part of WebFX, or SnapKit / CJDom?

[reportmill]

Maybe the best solution would be for WebFX to have its own copy of CJDom/webapi, to avoid the external dependency. I'm the only one currently using CJDom, and I'm happy to support the dependency, but it's actually just a simple bridge library - as much as possible, the APIs just forward to the real JSObjects via JNI (I keep forgetting to add an OpenSource license.txt to the repo).

At one point I added the glue code to CJDom to also support JxBrowser, which was kind of fun. It made it possible to run Java UI on the desktop using the Chrome engine for all rendering and platform specific code.

[salmonb]

Adding a dependency in WebFX is not an issue, especially since this would not be a simple core JAR dependency. As with TeaVM, this could live in a separate polyfill module, so it would have zero impact on existing GWT- or TeaVM-based WebFX applications. The TeaVM Elemental2 polyfill was added exactly this way.

From an architectural point of view, a CheerpJ backend could therefore be introduced as:

• a dedicated Elemental2 polyfill module (possibly backed by CJDom or similar), and
• a new executable target in the CLI (e.g. xxx-cheerpj) that would package this polyfill into the generated JAR.

That said, this would only make sense for WebFX if the polyfill itself is written and maintained by you (or by contributors on your side), as this is a CheerpJ-specific runtime layer and outside the current scope of WebFX’s core targets.

In that model, WebFX would generate the executable JAR, which you could then integrate into SnapCode.

Would that reply to your expectations?

[reportmill]

That sounds good - thanks for taking the time to look into it! I'll have to revisit this at a later date - or perhaps when there is more interest from the WebFX and/or CheerpJ community. I'm very interested in this, but also stretched pretty thin with my current set of projects :-).

I actually also just asked the OpenJFX discussion list if they thought adding a "Java2D/AWT" architecture implementation made sense - that might make sense here as well. Implementing a subset of JavaFX using Java2D/AWT might be an interesting way to get a large number of JavaFX apps to run anywhere the standard JVM already runs.

[FDelporte]

About JavaFX support in CheerpJ: announced (already some time), but not available yet...
https://cheerpj.com/our-roadmap-for-modern-java-in-the-browser/

Thanks to this feature, CheerpJ 4.0 will also introduce initial support for JavaFX, and will create the foundations to provide full support for SWT future releases. The support for these toolkits in CheerpJ marks a clear intention to allow most UI-based Java Desktop applications to run in CheerpJ.