A Java char corresponds to a UTF-16 code unit, and in some cases two consecutive chars (a so-called surrogate pair) are needed for one real Unicode character (codepoint).
XORing two valid UTF-16 sequences (i.e. Java Strings char by char, or byte by byte after encoding to UTF-16) does not necessarily give you another valid UTF-16 string - you may have unpaired surrogates as a result. (It would still be a perfectly usable Java String, just the codepoint-concerning methods could get confused, and the ones that convert to other encodings for output and similar.)
The same is valid if you first convert your Strings to UTF-8 and then XOR these bytes - here you quite probably will end up with a byte sequence which is not valid UTF-8, if your Strings were not already both pure ASCII strings.
Even if you try to do it right and iterate over your two Strings by codepoint and try to XOR the codepoints, you can end up with codepoints outside the valid range (for example, U+FFFFF (plane 15) XOR U+10000 (plane 16) = U+1FFFFF (which would the last character of plane 31), way above the range of existing codepoints. And you could also end up this way with codepoints reserved for surrogates (= not valid ones).
If your strings only contain chars < 128, 256, 512, 1024, 2048, 4096, 8192, 16384, or 32768, then the (char-wise) XORed strings will be in the same range, and thus certainly not contain any surrogates. In the first two cases you could also encode your String as ASCII or Latin-1, respectively, and have the same XOR-result for the bytes. (You still can end up with control chars, which may be a problem for you.)
What I'm finally saying here: don't expect the result of encrypting Strings to be a valid string again - instead, simply store and transmit it as a byte (or a stream of bytes). (And yes, convert to UTF-8 before encrypting, and from UTF-8 after decrypting).
what Java is using internally is irrelevant. As a user you can either access each char (with surrogates issues of course) or each codepoint. Whether Java uses internally UTF-16 or the colors of the moonboots little fearies are wearing has nothing to do with the question.
@SyntaxT3rr0r: Okay, maybe not optimally worded, I'm trying to edit this.
@SyntaxT3rr0r: XORing by codepoint does not help, either (see example now in the answer).
+1 - I agree with Paulo. XOR-ing is liable destroy the properties that make a Java String a valid UTF-16 String. If you do that, they become impossible to encode / decode.