Java has a mechanism for sending sysex messages piecemeal:

https://docs.oracle.com/javase/7/docs/api/javax/sound/midi/SysexMessage.html

In short: if you want to send a sysex message as several SysexMessage objects (as a stream essentially), possibly separated by a pause in time, then the FIRST SysexMessage has a status of 0xF0, and every SUBSEQUENT SysexMessage has a (java-special) "status" of 0xF7. The FINAL SysexMessage is the only one which is terminated with 0xF7. Here's an example of some messages demonstrating the scenario

SysexMessage[] foo = new SysexMessage[]
    {
    new SysexMessage(new byte[] { (byte)0xF0, 0x01, 0x02, 0x03, 0x04 }, 5),
    new SysexMessage(new byte[] { (byte)0xF7, 0x05, 0x06, 0x07, 0x08 }, 5),
    new SysexMessage(new byte[] { (byte)0xF7, 0x09, 0x0A, 0x0B, 0x0C }, 5),
    new SysexMessage(new byte[] { (byte)0xF7, 0x0D, 0x0E, 0x0F, (byte)0xF7 }, 5),
    };

You'd then send these messages.

EXPECTED RESULT on MIDIMonitor:

One single Sysex Message of the form

0xF0 0x01 0x02 0x03 0x04 .... 0x0D, 0x0E, 0x0F, 0xF7

ACTUAL RESULT on MIDI Monitor:

Sysex Message: 0xF0 0x01 0x02 0x03 0x04 0xF7
Invalid Message: 0x05, 0x06, 0x07, 0x08
Invalid Message: 0xF7, 0x09, 0x0A, 0x0B, 0x0C
Invalid Message: 0xF7, 0x0D, 0x0E, 0x0F, 0xF7

Not good.

MY GUESS: It looks like CoreMidi4Java is treating the 0xF7 of each subsequent message as actual data, rather than a "fake" status byte, and actually sending it on. It should be stripping out the initial 0xF7 from each such continuing Sysex Messge.