the pom.xml dependency reordering was necessary in order to get ExpectedException working.
What is the net effect of declaring that no exception is expected? Is it any different from not declaring anything?
Lists.newLinkedList() comes from Guava, which I like.
The issue isn't Guava. The issue is that it was created to replace new LinkedList<Integer>() (in this case), but as of Java 7 there's the diamond operator. If you read the javadoc for newList(), it says not to use it with Java 7 or later.
I like final stuff (I know I'm weird), please specify where I should make variables / fields non-final
I was thinking specifically of
final int inputLength = csq.length();
inputLength is only ever used as a parameter, so declaring it final is kinda overkill.
While you're working on the patch, another architectural concern has occurred to me. Assume I have a 64k limit. I append a message that's 65,530 bytes long. I then append a message that's 10 bytes long. The current implementation will drop the first message completely. Seems like it might be better to only drop the first line of the first message, just enough to trim it down. A partial message may be better than no message. Granted, it's probably not hugely useful to only have the tail of a message, but from a user's perspective it's less unexpected to get a partial message than to drop a large message entirely. One could make the same case for just cutting it down to the exact length instead of minding line boundaries... Jason Lowe, Karthik Kambatla, Varun Vasudev, Yufei Gu, any thoughts?
Oh, one more thing... Can we add a header that shows the content was trimmed? If we're not just clipping to the buffer size, it would be useful to have a way to notify the user that the message is not complete. In most cases it will be, so we want to be clear when it isn't.