Breaking changes in mongo-java-driver (ObjectId serialization), mentioned nowhere and without workaround


we stumbled upon a serialization problem with ObjectId, and after searching around, I found the commit and the related Jira ticket.

As mentioned in the commit: “This means that serialized instances of ObjectId prior to this change will be incompatible, but at least an exception will be thrown indicating the incompatibility.”

We can’t deserialize old objects with the new lib. This is a breaking changes introduced from 4.1 to 4.2, and it isn’t mentioned in the release note. And there is solution to be found, and this isn’t a minor changes.

Can you update the doc or at least have a landing page to talk about this?

Hi @Sylvain_Rouquette,

I’m sorry for the trouble you’re having. In trying to help one user out of a bind with a previous unintentional breaking change, we caused problems for you with an intentional one.

We can certainly update our docs to reflect this change.

Also, can you let us know on this thread your use case for serializing ObjectId instance using Java Object Serialization. The vast majority of our users as far as we are aware using either JSON or BSON to transmit ObjectId instances over the network, so we’re alway interested to know about other scenarios where those options did not seem appropriate.



maybe it’s bad practice, but we used ObjectId in our DTO, instead of converting them to String for example.

ActiveMQ, via spring-boot-starter-activemq, uses Java serialization API to store messages in its queues. We chose ActiveMQ because AWS wasn’t providing managed RabbitMQ instances.

If a message is generated by the old lib, and a service consumes the message with the new lib, it won’t be able to deserialize the message.

Thanks for your reply. I would say that it’s common practice to convert ObjectId to String in DTOs in order to avoid exposing implementation details of the database in the business model. But I’m sure you’re not the only ones who have done it the way you have.

Have you come up with a plan as to how to mitigate this problem in your application? I’d be happy to discuss it further if you’re interested.


we won’t do a migration, we will drain the queues and deploy the new services.