Sanny Sanoff submitted a major
pull request that’s already on the build servers.
It’s a very ambitious change and based on our internal benchmarks it does improve quite a few things in terms of
on-device performance.

It’s hard to tell how much of a difference will be felt in real world applications with changes like this as VM’s
are pretty different from one another. We find that the biggest performance differences we see is when we
improve the implementation of core API logic e.g. string handling primitives etc.

With the recent news that JavaScript builds are now available to a wider audience we also ran into some issues.

We are working on releasing an updated version of the VM based on the latest code from TeaVM
which will hopefully solve some of these problems. Since this is a big change it is taking a while but we hope to finish
it this week…​

One point that didn’t get enough attention when we released the original JavaScript port was an issue it has with
static initializers. TeaVM does some pretty insane things to make threading “feel” real despite
the fact that the browser is single threaded. Essentially every call to wait/notify etc. triggers a split in the generated
code that allows the VM to switch co-operatively to other code. For 98% of the code this is totally seamless as
proper code would eventually block somewhere.

However, static initializers are a bit of a special case here. It seems that its impossible to split them in a way
that allows this functionality. So you can still use static initializers but you can’t call wait/notify etc. within them.

Normally that’s not a big deal, however it becomes a big deal when you realize that this also applies to code you
invoke indirectly e.g. image loading IO would trigger wait for the IO operation to complete internally. The workaround
is to do image loading lazily and not in the static initializer, ideally we’d like a more robust workaround but since
this is a rather elaborate issue I’m not really sure how practical that would be.

We had some issues with gradle Android builds last week and we eventually changed the default build back to
ant just so we could get thru the week. We restored gradle builds today and hopefully fixed the issues with the
build process, if you notice anything this might be due to that…​

Please let us know at once if there are any recent regressions related to the Android build here.