Move msgpack value classes to another project msgpack-value by dmikurube · Pull Request #571 · msgpack/msgpack-java

Dai MIKURUBE

@dmikurube My preference order is:
First, release Timestamp support without introducing such interface changes like this PR. msgpack-java has been carefully implemented so as not to use any TypeProfile, which will be generated when extending classes (e.g., implementing interfaces, extending abstract classes). In an old benchmark, extending any classes had non-negligible overhead. I'm not sure this result still holds in modern JVM, though. The next msgpack-java version would be 0.9.0.

If we release a next msgpack-java version and the performance difference is negligible, I'd like to simplify all of the interfaces. by changing the value classes to always use immutable values, and discard existing immutable value interfaces, which is just adding complexity to the entire code base. Then, it would be possible to make the value interfaces more stable. For example, creating msgpack-spi module and introducing org.msgpack.spi package. Value classes will be org.msgpack.spi.Value.

If we will introduce such breaking changes, I'm not sure how valuable it is to split the msgpack-value as a separate module at this moment as embulk SPI will be broken again by such a change.

I don't think we can create org.msgpack.spi soon, so a reasonable release plan would be like this:

0.9.0 adds TimestampValue
0.10.0 split value interface like this PR. Adding JMH based benchmark would be good.
0.11.0 (This might be a year later or really quick if I have a chance to work on it) introduce org.msgpack.spi and separate packer/unpacker/value impl.
1.0.0 finalize