microstream-one
Handle changing class definitions at runtime
Developing support technologies like JRebel (#26) or Quarkus (Ticket #J505) use "hot code replacement", i.e. change classes of a live Java process at runtime.
This causes MicroStream to fail since the metadata derived from the handled classes during initialization do no longer match the classes.
This is no problem at all for any production usage, since classes don't get changed there during runtime. However, it does cause confusion for developers using MicroStream with a hot code replacement technology. They assume MicroStream handles those cases (or probably that it makes no difference ) and wonder why they get an error.
The solution would be to provide some kind of Legacy Type Mapping at runtime. Since LTM is already implemented, this shouldn't be too hard to do, albeit the usual rule about the devil being in the details should apply here, too. E.g. too many changes might confuse the mapping logic. Changes during the execution of a binary operation (store/load) might ruin the result, etc.
Such a solution would also require to have access to some kind of "class change callback". Preferably a central one provided by the JVM directly that every hot code replacement technology MUST use because there is no other way to do it. Apart from that, every hot code replacement technology would require its own MicroStream compatibility plugin that hooks the runtime LTM logic up with the technology's mechanism. That would be ... messy.
For now we should check if we can detect class changes at runtime and throw a proper exception.
Are there any updates regarding this issue? I am currently trying to use microstream in a Quarkus application and it works very well, but not in the development mode which uses "hot code replacement".
Found a workaround for my problem with Quarkus: https://stackoverflow.com/a/73698838/19983149