We are trying to improve the visibility of Codename One within search engines and as part of that
we think we can also help you guys improve your visibility. When you submit your apps to the app gallery we
provide dofollow links to your website/app store listings. We’d appreciate if you place dofollow links back to
https://www.codenameone.com/ which you can place in a very hidden/unobtrusive way. This helps us increase
our page rank and as a result will improve your page rank as we link back to you.
To add your app to the app gallery just comment on the post below with full details/link to your app. Make sure
to include the package name, we need to verify that the app was built with Codename One and we don’t accept
any other apps so please don’t post such entries as they would be deleted and comment links are “nofollow”
FYI the moderation system might block posts with links and put them in the moderation queue, we get a notification
on that and approve the comments if they are indeed valid.
Performance Optimizations For ParparVM
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
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.
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…
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
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
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.
Retry on the Google Play Services Patch
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.