Skip to content

Initialize ObjectId, ClientMetadataHelper at runtime, GraalVM #1078

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 6, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -13,4 +13,4 @@
# See the License for the specific language governing permissions and
# limitations under the License.
#
Args = --initialize-at-run-time=com.mongodb.UnixServerAddress,com.mongodb.internal.connection.SnappyCompressor
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Args = --initialize-at-run-time=com.mongodb.UnixServerAddress,com.mongodb.internal.connection.SnappyCompressor,org.bson.types.ObjectId,com.mongodb.internal.connection.ClientMetadataHelper
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.