Just in 1h after release first reports arrived. It resulted in failure to link with messages like:

Undefined symbols for architecture arm64: “_[j]java.lang.Object.notifyAll()V[lookup]”,

Moment here: Object.notifyAll is final method and doesn’t require [lookup] trampoline but quick look shows that its being invoked now with invokeinterface JVM instruction instead of invokevirtual as it was before.

Long story short: this happen due Java18 was used for compilation on build machine. And even if we target Java8 when compiling runtime different byte code was generated due applied JDK-8272564.

In short term – planned 2.3.18 release using Java 15 on host. Also we have to support method lookup for Object methods when these invoked on interfaces as it described in jvms-5.4.3.4 item 3.

AltPods were updated to v1.23.0-SNAPSHOT to sync with recent releases.

Updated pods

• Adaptry 1.16.10 to 1.17.1
• AppLovinSDK v11.3.3 to v11.4.1
• Charts v4.0.2 to v4.0.3
• Facebook v13.1.0 to v13.2.0
• Firebase v8.14.0 to v9.1.0
• Fyber v8.1.4 to v8.1.5
• OneSignal v3.10.2 to 3.11.1
• Singular v11.0.6 to v11.0.7
• UnityAds v4.1.0 to v4.2.1

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.23.0-SNAPSHOTS version. Source code @github

Updates are not fully tested, please open issue if bug found.

RoboVM stopped to be Java7+ runtime (Android 4.4 to be exact). However it doesn’t stop users to compile it against more recent Java like java 11.
It works with some amount of constraints but sometime changes are breaking. Like JEP181 that causes java8 scenarios doesn’t work anymore with RoboVM (issue #852).
Long story short: with JEP181 changes compiler doesn’t generate accessors to private fields for nested classes. And RoboVM truly produces IllegalAccessError: Attempt to access private method/variable.
Here is a sample code to reproduce:

It is a 5-year-old issue that was not bothering me much with my pet projects. Till I started playing with something big. In result with my default 4GB heap setting for Idea I was not able to complete a build due heap exhaustion:

Things got better with 8GB heap settings:

This issue was mentioned multiple times over all channels and all reports have the following in common:

• issue usually was seen in crash reporters;
• no steps or information how to reproduce;
• no simple project to reproduce;
• production source code can’t be shared for investigation;
• crash is related to heavy network activities;
• crash log looks similar to bellow:

rvmCreateVM
SIGABRT ABORT 0x00000001d5219414

Crashed: Thread
0  libsystem_kernel.dylib         0x1d5219414 __pthread_kill + 8
1  libsystem_pthread.dylib        0x1f2d74b50 pthread_kill + 272
2  libsystem_c.dylib              0x1b06f7b74 abort + 104
3  RoboVMMobile                   0x1060a77b0 rvmCreateVM + 4386699184
4  RoboVMMobile                   0x1060a51ec rvmInitialize + 4386689516
5  RoboVMMobile                   0x10609d9a8 _bcInitializeClass + 4386658728

Things changed once Benjamin Schulte @MrStahlfelge reported unknown rare crash that was happening approximately once per 100 launches and ErgoWallet is opensources. 1 crash per 100 launches sound good to track the bug.

Root case

Issue mentioned in report #641 Code is quite simple to reproduce:

package a;
public class A {
    protected void foo(){};
}

package b;
import a.A;
public class B extends A {
    public void test() {
        Runnable r = this::foo;
        r.run();
    }
}

Root case

Xcode13.3 bring unaligned pointer problem during linking but also debugger launch was crashing with:

[ERROR] Couldn’t start application java.lang.IllegalArgumentException: there is no region for addr @10000101effaa0 at org.robovm.debugger.utils.bytebuffer.CompositeDataBuffer.setPosition(CompositeDataBuffer.java:37)

0x10000101effaa0 indeed looks weird for memory address, even looks like tagged pointer at first (but not). Anyway it introduced a level of complication that is not allowing debugger to read internal RoboVM structures like class info anymore.

LC_DYLD_CHAINED_FIXUPS and LC_DYLD_EXPORTS_TRIE

This issue is rare and affects most user. It can be seen once registered for default Java exception handler.
Scenario for this crash is following:

• iOS application goes to background/suspend (just enough to minimize it);
• resumed after > 10s.

Crash is rare but more user you have more crashes you will see.

Root case

FinalizerWatchdogDaemon looks after FinalizerDaemon and responsible to terminate App if object spends too much time in .finalize() call. Scenario is following:

• FinalizerDaemon picks object to dispose and calls .finalize() to allow object performing clean-ups;
• FinalizerWatchdogDaemon detects it and startes looking for it;
• Application is minimized/suspended;
• all threads are suspended (including Daemons);
• (time passed, 10+ seconds);
• Application is resumed;
• .finalize() is still busy;
• FinalizerWatchdogDaemon has already counted 10+ seconds its being observing class doing finalization and terminates app, considering that finalizer is stuck.

Trying to reproduce

AltPods were updated to v1.22.0-SNAPSHOT to sync with recent releases.

Updated pods

• Adaptry 1.16.9 to 1.16.10
• AppCenter 4.4.1 to 4.4.2
• AppLovinSDK v11.3.1 to v11.3.3
• Facebook v13.0.0 to v13.1.0
• Firebase v8.13.0 to v8.14.0
• OneSignal v3.10.1 to v3.10.2
• Singular v11.0.4 to v11.0.6
• UnityAds v4.0.1 to v4.1.0

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.22.0-SNAPSHOTS version. Source code @github

Updates are not fully tested, please open issue if bug found.

Xcode started complaining about unaligned pointer in RoboVM binaries since 8.3 (issue #123) but these warnings (altogether with other possible) were suppressed with -w option. But with Xcode13.3 it started failing with error ld: unaligned pointer(s) for architecture arm64 on some projects (while compiled ok but probably with changes to it might fail).

Trying to reproduce