See thread http://mail.openjdk.java.net/pipermail/i18n-dev/2012-May/000630.html. Here are some notes regarding the changes.
(1) MS936 and GBK mappings have been updated to follow maps used by MS MultiByteToWideChar and WideCharToMultiByte
(especially for those eudc/pua entries in 0xA140 - 0xA7A0 range, which is also the same as the mapping GB18030 uses.
(2) For GBK.map added the eoro sin entry U+20AC to 0xA2E3, which follows GB18030 (MS936 maps 20ac to 0x80)
(3) "412 non-UDC characters missing" suggestion obvious is in-accurate. It appears the code points cited in attached CodePage936 are the result of incorrect use of WideCharToMultiByte. Those are the "best fit" result when WideCharToMultiByte is invoked without flag WC_NO_BEST_FIT_CHARS is specified.
(4) These code point mapping changes are "in-compatible" in nature. However given the fact that the GB18030 (the spec owner of Chinese encoding) and MS936/icov-gbk (vendor implementation) all use the same mappings, it does not seem reasonble for Java MS936/GBK to stick with the "wrong" mappings, especially these are eudc/pua code points. So I believe we should go ahead and just udpate them.