Initialize ObjectId, ClientMetadataHelper at runtime, GraalVM

[katcharov]

JAVA-4856

also:

JAVA-3580
JAVA-4864

Manually tested, via something like:

        System.out.println("oid: " + new ObjectId(Date.from(Instant.ofEpochSecond(99, 99))));
        System.out.println(ClientMetadataHelper.CLIENT_METADATA_DOCUMENT);

Running the jar, and then two runs of the native image:

oid: 0000006343ef8f0fabeae35b
{"driver": ...
=====
oid: 00000063886af5402f11180f
{"driver": ... "platform": "Java/GraalVM Community/17.0.6+10-jvmci-22.3-b13"}
=====
oid: 00000063886af5402f11180f
{"driver": ... "platform": "Java/GraalVM Community/17.0.6+10-jvmci-22.3-b13"}

Generates the same oid for the latter two, and reports GraalVM.

After changes:

oid: 00000063113a125a8556fcb1
{"driver": ...
=====
oid: 0000006341ef117b012d53d8
{"driver": ... "platform": "Java/Oracle Corporation/unknown-version"}
=====
oid: 00000063b0e5d506f6beef95
{"driver": ... "platform": "Java/Oracle Corporation/unknown-version"}

oids are different, and the platform is no longer GraalVM.

[katcharov]

I saw that we had JAVA-3580 open to test UnixServerAddress and SnappyCompressor, which were proposed in #527. I do not know how we might test these, since the original had no reproducer. I do not understand why these were originally added, since they seem to never have had statics (initialized via --initialize-at-build-time). Either these were never needed, or there is some other form of initialization we should check our codebase for. Any ideas?

In any case, my testing shows that classes are being picked up from native-image.properties, so I think we should consider these sufficiently tested.

[jyemin]

I'm a bit surprised this works because ObjectId is in the bson jar not driver-core, but I guess the native image compiler doesn't care.
But for anyone that is using the bson library directly, it seems like this more properly belongs in the bson jar file.

[katcharov]

I added ObjectId to bson. Tested by replacing mongodb-driver-sync with bson as a dependency, and confirming that the oid did not change between runs, and then changed after the fix.

[jyemin]

Looking at 9c3d626. I'm surprised this works without the same change to bson/build.gradle as was made to driver-core/build.gradle in that commit. Any ideas, @rozza ?

[rozza]

Regarding resources? Seems we adopted in #527 a non-typical structure for resources in driver-core: src/resources as opposed to the default location: src/main/resources https://docs.gradle.org/current/userguide/java_plugin.html

@katcharov used the default structure so no build changes needed.

[jyemin]

Let's take the opportunity here to make them consistent. If there's no reason for the non-standard location of the driver-core resources, we can move that one to the default location.

[katcharov]

Moved resources, and repeated all prior manual tests.