teavm support

[DaanVanYperen]

https://github.com/konsoletyper/teavm-libgdx

[DaanVanYperen]

junkdog: Have you looked at teavm recently? Would be lovely to dump gwt - it should give a slightly more flexible lowest common denominator.

@junkdog It doesn't seem widely adopted yet, both dragome and teavm don't show up in google trends. Maybe we should ask @konsoletyper if the gdx team has shown interest to board teavm-libgdx as a module, and if teavm-gdx is complete enough. If we get all our games ported it might facilitate growth for everyone involved.

[konsoletyper]

I haven't seen great interest from libGDX community in TeaVM port. But I am not a good at community work, so you are free to try. Of course, I have no time to support teavm-libgdx, but there is already something to start with. For what purpose are you going to use TeaVM instead of GWT?

As for popularity. Yes, TeaVM has no support of big company like Google. But every project has to start to gain its popularity somewhere. Recently, CodeName One team started to adopt TeaVM for their JavaScript port. Can this be a good reason?

[DaanVanYperen]

Thanks for the quick response @Konsoletyper! I hope you didn't take my google trends comment as a dismissal, we're very grateful for efforts like yours and personally I feel it's more a question of when it gains momentum, not if. Congrats on CodeName One!

Beyond the typical GWT gripes our motivation would be providing some compile time https://github.com/junkdog/artemis-odb/wiki/Bytecode-weaving related features concerning boilerplate and performance. Filling that feature matrix up on all platforms! ;)

At this time, given the interest from libGDX devs we'd probably wait it out for now, or perhaps experiment a bit with it. If someone takes up the lead on teavm-libgdx i'm certain we'd provide a teavm module as well.

[konsoletyper]

@DaanVanYperen I see. I'm not sure if TeaVM won't suffer from some of GWT disadvantages. For example, it won't ever support reflection. As for bytecode weaving, it should be tested carefully. I believe, there's no problem for TeaVM to handle transformed bytecode, but I'm not sure that it will give the same performance boost as in the real JVM.

[DaanVanYperen]

Point taken.

Teavm-libgdx's existence motivated this ticket in the backlog. We're always eager to explore solutions that might give us more mobility and aligns better with our goals, even if there are limitations like you mentioned.

Anyway, thanks for taking the time to reply!

[junkdog]

it won't ever support reflection.

@konsoletyper Not even a "reflection cache", similar to how libgdx deals with reflection in their GWT backend?

While I think that the hotspot optimization weaving we do wouldn't carry over to javascript, artemis-odb also does bytecode weaving w.r.t. injecting system profiling and rewriting component types (to cut back on boilerplate, mostly). These would be neat if they were supported when building for the web too, but it's impossible with GWT due to it parsing source and not bytecode.

Anyway, very interesting project - I hope teavm catches on!

[konsoletyper]

@junkdog what do you exactly mean for reflection? Examining classes, fields, methods and annotations in possible. Method.invoke is not possible, without explicit list of methods that are possible to call, which, AFAIR, is similar to libGDX. Also note, that TeaVM CPS generator builds call graph to find methods which need to be split for async invocation. With Method.invoke, when everything can be called, you end up with async explosion, when every call of every method will be claimed as async and therefore split. This leads so significant performance degradation and bloating of the generated JavaScript.

[junkdog]

It's for our dependency injection mechanism during initialization: I only want to scan classes and set field values, there are no dynamic method invocations going on - does that mean we're spared the async?

We could rewrite it to be compile-time instead (and it might make sense, if we can rely on bytecode all the way), but it'd break some edge case features; and realistically, we'd still need to provide a reflection-based fallback.

[DaanVanYperen]

@junkdog What do we use reflection for anyway, obtaining instances during pooling, events, what else? Pretty sure if we really want to we can get this working with similar gotcha's as with GWT, though I wonder if it isn't going to be just as exotic a solution.

I assume entity instancing (via reflection) might also be an issue?

[junkdog]

Probably... meh, but, yeah - we do have some constructor invocation happening reflexively, I guess those may be a cause for concern?

[konsoletyper]

@DaanVanYperen @junkdog can code that uses reflection be separated into a service that has the reflection-based implementation in JVM and the code generated implementation in TeaVM or GWT?

[junkdog]

A lot could be, not sure everything fits the bill though. Worth investigating, want to have a reflection-free approach on android anyway - but the ROI is pretty small, so it was put on hold.

[DaanVanYperen]

That's basically how it works now. We have a bridge that handles all the reflection calls. Our GWT reflection is based on the LibGDX implementation of a (pre-compile?) generated static reflection cache.

[DaanVanYperen]

Re-open if we ever find ourselves with time! Aggressive backlog grooming!