Skip to content
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

size of ObjectOutputStream is not equal when two Maps are equal #462

Open
mores opened this issue Dec 24, 2022 · 2 comments
Open

size of ObjectOutputStream is not equal when two Maps are equal #462

mores opened this issue Dec 24, 2022 · 2 comments

Comments

@mores
Copy link

mores commented Dec 24, 2022

In my use case my Map will contain a Map for both keys and values.

I have run into a weird case where I found two maps that are equal but the size of ObjectOutputStream are not. ( Which ChronicleMap uses under the covers ).

When using a java.util.HashMap my use case works as expected.
When I substitute in ChronicleMap, my use case no longer works.

Here is a link to the code that shows the issue:
https://github.com/mores/maven-examples/blob/ac6012ca1236ad460f3b3767037531fdb2e3dffd/offHeapMap/src/test/java/org/test/MapTest.java#L76

I am able to reproduce this bug on ubuntu using both 1.8.0_161 and 11.0.17

@alamar
Copy link
Contributor

alamar commented Dec 26, 2022

Such is the limitation of ObjectOutputStream mechanism of the JVM - it will write repeating objects by handle. There is an unshared mechanism that could override that, but even if it was used it will break down on recursive data structures.

You can specify your own readers / data access for such maps of maps, by using ChronicleMapBuilder.keyReaderAndDataAccess().

@mores
Copy link
Author

mores commented Dec 26, 2022

If that is the default behavior, should ChronicleMap throw an exception when a Map is used as a key.....
"keyReaderAndDataAccess is required when using a Map as a key"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants