Add utility methods to pack/unpack to/from byte arrays efficiently

[frsyuki]

This pull-request assumes #304 and #305, and provides utility methods to use msgpack-java more efficiently. Intention of this pull-request is that users use msgpack-java using intuitive APIs and those code become automatically the fastest code.

• Added MessageBufferPacker class and MessagePack.newBufferPacker() method to serialize objects into a byte array (or list of byte arrays). This is easier than ByteArrayOutputStream and a lot more efficient. Internally, this implements the optimization mentioned at Add support for external buffer pools to packer #305.
• Added MessagePack.newDefaultUnpacker(byte[], int, int)
• Size of both input and output buffers are configurable using MessagePackFactory API.

[komamitsu]

Storing default factory class as a mutable static variable doesn't seem a good idea. For instance, if a dependent library uses MessagePack and internally sets a customized factory, it'll unexpectedly affect the application that uses MessagePack.

BTW, I'm wondering why we don't directly use MessagePackFactory without MessagePack.

[xerial]

Good point. This setter for the default factory should be removed.

[xerial]

Do we need these configuration setters in MessageUnpacker? I think these method should be moved to the factory (or config) side.

[xerial]

@komamitsu I have finished the code review and applied your comments and made minor modifications. Let me know if you finish the review. I'll merge this PR (by resolving conflicts with the v07-develop)

[komamitsu]

We'd better create a constant variable and replace 8192 with it.

[komamitsu]

It should be if instead of while here?

[xerial]

No. MessageBufferInput might return 0-size buffer.

[komamitsu]

Non-nil value is allowed?

[xerial]

Nil is 1-byte format and this is already checked with mf.getValueType(). readByte() is used for forwarding the buffer position.

[komamitsu]

Ah, mf.getValueType() == NIL means the value is nil. Okay.

How about changing https://github.com/msgpack/msgpack-java/pull/310/files#diff-6a54557ce799041aa918fa8fa48bc78dR537 as well?

[xerial]

ok.

[komamitsu]

[trivial] Unnecessary code.

[komamitsu]

How about buffer or something instead of one character variable name?

[komamitsu]

LGTM

[frsyuki]

@xerial @komamitsu Thank you!

[frsyuki]

@xerial about MessagePack.Code vs MessageFormat.Code: I wanted users to not aware of formats because most of users care about semantics (API) but don't want to care about syntax (formats). I first moved MessagePack.Code to MessageFormat.Code because MessagePack is the entry point (which is used by most of users) and users will need to care about methods/classes in it, and that's not expected to have Code there.

How do you think about this?

[frsyuki]

@xerial about MessagePackFactory: I preferred to have a single FactoryClass to make it easy to configure MessagePack as a single library (maybe using a configuration file). I expected following example use case:

MessagePackFactory factory = MyIoManagerConfigurator.loadMessagePackConfiguration("myio.config");
MessagePacker packer = factory.newPacker(...);
MessageUnpacker unpacker = factory.newUnpacker(...);

But as you mention, having 2 separated classes contributes to shorten parameter names. So, it was just a preference.

[frsyuki]

@xerial about MessagePackFactory.inputBufferSize and MessagePackFactory.outputBufferSize. Sorry, my code had a bug where newPacker(OutputStream), newPacker(WritableChannel), newUnpacker(InputStream), and newUnpacker(ReadableByteChannel) don't pass inputBufferSize or outputBufferSize parameters to constructors of OutputStreamBufferOutput, ChannelBufferOutput, InputStreamBufferInput or ChannelBufferInput. And this problem still exists in the latest code.

I think buffer size should be configurable because it's a trade-off of performance and memory consuption.

[xerial]

@frsyuki Defining Code inside MessagePackFormat introduces unnecessary dependencies between MessagePacker/Unpacker to MessageFormat. So extracting Code class outside MessagePack might be better.