為什么在Java中char不能自動裝箱到Character？

Question

在努力改進ESAPI的編碼方法以處理非BMP字符時，我遇到了意外的行為。 至少可以說這很有趣...

本單元測試：

public void testCSSEncodeChar0x100()
{
    char in = 0x100;
    String inStr = Character.toString(in);
    String expected = "\\100 ";
    String result;

        result = cssCodec.encodeCharacter(EMPTY_CHAR_ARRAY, in);
    // this should be escaped
        assertFalse(inStr.equals(result));
        assertEquals(expected,result);
}

我腦子里只有一種目標方法。 我有兩種方法：

@Override
public String encodeCharacter( char[] immune, Character c ) {
    return ""+c;
}

@Override
public String encodeCharacter( char[] immune, int codePoint ) {
    return new StringBuilder().appendCodePoint(codePoint).toString();
}

我本來期望Java來autobox變量in的Character ，而是它上溯造型得到了一個int ，最終調用第二種方法。

嘗試過Google ，但對於這種非直覺的行為沒有得到任何答案。

至於有效的方法，只需將in的類型從char更改為Character解決問題。

Answer 1

Java 可以完美地將char裝箱到Character 。 這將正常工作：

Character c = in;

但是，為了向后兼容，過載解析會在多個階段中發生。 在Java的早期版本中（自動裝箱前），您已經可以使用第二種方法（因為從char到int轉換一直在擴大），但是第一種方法卻沒有……所以，這是我們選擇的第二種方法。

當您將in的類型從char更改為Character ，僅第一種方法適用，因此將其代替。

JLS 15.12.2包含以下詳細信息：

該過程的其余部分分為三個階段，以確保與Java SE 5.0之前的Java編程語言版本兼容。 這些階段是：

• 第一階段（第15.12.2.2節）執行重載解析，不允許裝箱或拆箱轉換，也不允許使用可變arity方法調用。 如果在此階段未找到適用的方法，則處理將繼續進行到第二階段。 [...]

• 第二階段（第15.12.2.3節）在允許裝箱和拆箱的同時執行重載解析，但仍排除使用可變arity方法調用。 如果在此階段未找到適用的方法，則處理將繼續進行到第三階段。 [...]

• 第三階段（第15.12.2.4節）允許將重載與可變arity方法，裝箱和拆箱相結合。