• I finally realized that the out of memory issue came from com.hazelcast.client.HazelcastClient, not Hazelcast Server, which is ridiculous. I feel like this is a bug in Hazelcast 5.2.1 and I need to adjust the target version of the PR.

• I'll keep investigating this after the com.hazelcast:hazelcast:5.3.0 release, it's so weird.

• @mhalbritter Hi, I want to know if you know why calling the method of com.hazelcast.client.HazelcastClient will cause the Github Actions device to crash? This branch is normally executed locally ./gradlew clean test -Pcoordinates=com.hazelcast:hazelcast:5.2.1, but Github Actions will crash due to device restrictions.
• I have no idea about this. Hazelcast 5.1.5, 5.2.0, 5.2.1 showed the same problem in Github Actions. I understand that this seems to be the problem of Hazelcast, but I can't find the relevant issue.
• 

Hey, no idea why the Github Actions won't run. I have no broader experience with either Hazelcast nor Github Actions, so I'm afraid I can't really help on that.

Hey, no idea why the Github Actions won't run. I have no broader experience with either Hazelcast nor Github Actions, so I'm afraid I can't really help on that.

• From this perspective, I don't think we should consider incorporating this PR at GraalVM Reachability Metadata 0.2.6. Of course, if a friend submits another hazelcast PR and gets merged, I'd be happy to try to add more unit tests to the next release milestone.

• So according to the findings of @fniephaus in Add support for com.hazelcast:hazelcast:5.2.1 #122 (comment), I determined that Hazelcast has a completely different port performance in Github Actions than that of local devices. And this actually didn't print any errors. So I specified all ports in linghengqian-scratches/graalvm-trace-metadata-smoketest@7f6a0ee and put the processing into the current PR.

• At the same time, because Hazelcast is difficult to specify the port on JCache, I replaced System.setProperty("hazelcast.jcache.provider.type", "client") with System.setProperty("hazelcast.jcache.provider.type", "member"), which is missing part of the unit tests related to https://docs.hazelcast.com/hazelcast/5.2/jcache/providers#hide-nav, but I don't think this will affect.

• Due to a new discovery at Add support for io.etcd:jetcd-core:0.7.5 #170, the org.junit.jupiter.api.Timeout annotation cannot be used under nativeTest, so I introduced org.awaitility:awaitility:4.2.0 to test the timeout behavior of HazelcastClient.

• Regarding the problem of serialization-config.json of javax.cache:cache-api:1.1.1, I misunderstood the meaning of Error Log before, and I have modified it to the GraalVM reachability metadata in the conditional style. I now know that this Log means that if and only if the java.lang.Object class is reachable, consider the javax.cache.configuration.FactoryBuilder$SingletonFactory entry. I am at linghengqian-scratches/graalvm-trace-metadata-smoketest@80bc33f fixes this, and addresses the current PR as well.

 JUnit Jupiter:HazelcastTest:testJCache()
    MethodSource [className = 'com.lingh.HazelcastTest', methodName = 'testJCache', methodParameterTypes = '']
    => com.oracle.svm.core.jdk.UnsupportedFeatureError: SerializationConstructorAccessor class not found for declaringClass: javax.cache.configuration.FactoryBuilder$SingletonFactory (targetConstructorClass: java.lang.Object). Usually adding javax.cache.configuration.FactoryBuilder$SingletonFactory to serialization-config.json fixes the problem.
       org.graalvm.nativeimage.builder/com.oracle.svm.core.util.VMError.unsupportedFeature(VMError.java:89)
       org.graalvm.nativeimage.builder/com.oracle.svm.core.reflect.serialize.SerializationSupport.getSerializationConstructorAccessor(SerializationSupport.java:143)
       java.base@17.0.5/jdk.internal.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:48)
       java.base@17.0.5/jdk.internal.reflect.ReflectionFactory.generateConstructor(ReflectionFactory.java:463)
       java.base@17.0.5/jdk.internal.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:455)
       java.base@17.0.5/java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1443)
       java.base@17.0.5/java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:412)
       java.base@17.0.5/java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:384)
       java.base@17.0.5/java.security.AccessController.executePrivileged(AccessController.java:168)
       java.base@17.0.5/java.security.AccessController.doPrivileged(AccessController.java:318)
       [...]

• This PR is ready for review.

• Since Add support for javax.cache:cache-api:1.1.1 #176 was merged, I removed the manually added javax.cache:cache-api:1.1.1 GraalVM reachability metadata in this PR in the latest commit.

• It seems that since this week, the current Git CI has encountered a problem. Every time a PR is merged, all unclosed PRs will be outdate.

• Since Add support for javax.cache:cache-api:1.1.1 #176 was merged, I removed the manually added javax.cache:cache-api:1.1.1 GraalVM reachability metadata in this PR in the latest commit.
• It seems that since this week, the current Git CI has encountered a problem. Every time a PR is merged, all unclosed PRs will be outdate.

We changed some repo configuration so it shouldn't happen anymore. If that doesn't solve the problem, we will explore some other options