資訊專欄INFORMATION COLUMN
摘要：但是將導(dǎo)入工程后，在使用時(shí)會(huì)出現(xiàn)等錯(cuò)誤消息。初步認(rèn)為是與自帶的沖突。再運(yùn)行工程，這個(gè)錯(cuò)誤不再出現(xiàn)了，奇跡般的沒(méi)問(wèn)題了。我的理解是這樣，不知道對(duì)不對(duì)，歡迎大俠指正。工程中下默認(rèn)的是，而則應(yīng)該是。所以按照該文的解決方法，更改就好了。
JSON解析庫(kù)有很多，諸如Jackson,Json-lib,org.json,Gson和fastjson等，但是fastjson以其解析速度最快而脫穎而出。詳細(xì)的測(cè)試地址如下：
https://github.com/eishay/jvm-serializers/wiki/Staging-Results
fastjson是國(guó)內(nèi)alibaba公司的wenshao開(kāi)發(fā)的，項(xiàng)目Git地址:
https://github.com/alibaba/fastjson
今天測(cè)試了下發(fā)現(xiàn)fastjson挺好用，比Android自帶的org.json庫(kù)要好用多了。當(dāng)然我沒(méi)有對(duì)fastjson的性能進(jìn)行測(cè)試，只是因?yàn)锳ndroid自帶的不太好。
在普通的java項(xiàng)目下，只需要導(dǎo)入fastjson.jar就可以，無(wú)需依賴其他包，這一點(diǎn)相比json-lib要好多，json-lib依賴五六個(gè)包。但是將fastjson.jar導(dǎo)入Android工程后，在使用時(shí)會(huì)出現(xiàn) java.lang.NoClassDefFoundError:can"t find com.alibaba.fastjson.JSON等錯(cuò)誤消息。
初步認(rèn)為是與Android自帶的org.json沖突。于是Build Path->Configure Build Path->Order And Export下將fastjson.jar上調(diào)至Android xx.jar上（xx為android 版本號(hào)）。再運(yùn)行工程，這個(gè)錯(cuò)誤不再出現(xiàn)了，奇跡般的沒(méi)問(wèn)題了。
然后現(xiàn)在再調(diào)整fastjson.jar和Android.jar順序也不會(huì)出現(xiàn)can"t not find com.alibaba.fastjson的錯(cuò)誤，不知道為何，繼續(xù)看。
文章Java虛擬機(jī)類加載順序講解了java 虛擬機(jī)加載class和jar包的順序。
bootstrap classloader ->extension classloader->system classloader
其中bootstrap引導(dǎo)類加載器;
extension classloader擴(kuò)展類加載器，它負(fù)責(zé)加載JRE的擴(kuò)展目錄（JAVA_HOME/jre/lib/ext或者由java.ext.dirs系統(tǒng)屬性指定的）中JAR的類包;
system classloader系統(tǒng)（也稱為應(yīng)用）類加載器，它負(fù)責(zé)在JVM被啟動(dòng)時(shí)，加載來(lái)自在命令java中的-classpath或者java.class.path系統(tǒng)屬性或者 CLASSPATH操作系統(tǒng)屬性所指定的JAR類包和類路徑.
該文中還有一句話是這么說(shuō)的，應(yīng)該能解決我們的疑惑：
“此外類加載還采用了cache機(jī)制，也就是如果 cache中保存了這個(gè)Class就直接返回它，如果沒(méi)有才從文件中讀取和轉(zhuǎn)換成Class，并存入cache，這就是為什么我們修改了Class但是必須重新啟動(dòng)JVM才能生效的原因?！?/p>
我想應(yīng)該是Android虛擬機(jī)中已經(jīng)有了fastjson的cache了，所以導(dǎo)致如何更改項(xiàng)目的fastjson.jar和Android.jar順序都不會(huì)有任何反應(yīng)。我的理解是這樣，不知道對(duì)不對(duì)，歡迎大俠指正。
解釋到這里，也解決了我另外一個(gè)疑問(wèn)，就是在Android的工程中新建一個(gè)java類，并生成main方法，然后Run->Java Application. 結(jié)果會(huì)出現(xiàn)如下的錯(cuò)誤：
# # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (classFileParser.cpp:3494), pid=5940, tid=5632 # Error: ShouldNotReachHere()
這個(gè)問(wèn)題的產(chǎn)生就是和bootstrap classloard 有關(guān)了，文件上右鍵Run As->Run Configuration選擇Java Application下的這個(gè)Java類，然后選擇右側(cè)的Classpath標(biāo)簽頁(yè)下有兩個(gè)目錄，分別是Bootstrap Entries 和 User Entries。
Android工程中Bootsrap下默認(rèn)的是Android Classpath Container，而Java則應(yīng)該是JRE System Library。所以按照該文Error: ShouldNotReachHere()的解決方法，更改就好了。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/64035.html
摘要：某年某月的某一天，本汪在某個(gè)奇葩的公司，接手了某個(gè)奇葩的項(xiàng)目，遇到了一些奇葩的事情，就掉進(jìn)關(guān)于做轉(zhuǎn)換時(shí)，那些關(guān)于首字符大小寫(xiě)的坑?？邮鬃址?xiě)，第二個(gè)字符大寫(xiě)的鍵名這個(gè)坑與相關(guān)，嚴(yán)格來(lái)說(shuō)，應(yīng)該是挖的坑。 某年某月的某一天，本汪在某個(gè)奇葩的公司，接手了某個(gè)奇葩的項(xiàng)目，遇到了一些奇葩的事情，就掉進(jìn)關(guān)于fastjson做bean to json轉(zhuǎn)換時(shí)，那些關(guān)于首字符大小寫(xiě)的坑。 這個(gè)奇葩項(xiàng)目...
數(shù)據(jù)傳輸使用json格式再方便不過(guò)了。fastjson 由阿里巴巴那伙人使用Java語(yǔ)言編寫(xiě)，號(hào)稱最快的JSON庫(kù)前兩天遇到一個(gè)問(wèn)題 后臺(tái)的數(shù)據(jù)轉(zhuǎn)化為json字符串后發(fā)送到前臺(tái)出現(xiàn)了$ref字樣的東西，后來(lái)明白了這是引用，在傳輸?shù)臄?shù)據(jù)中出現(xiàn)相同的對(duì)象時(shí)，fastjson默認(rèn)開(kāi)啟引用檢測(cè)將相同的對(duì)象寫(xiě)成引用的形式.說(shuō)到引用分為兩種，重復(fù)引用和循環(huán)引用 重復(fù)引用 指一個(gè)對(duì)象重復(fù)出現(xiàn)多次 循環(huán)引用 指你...
摘要：?jiǎn)栴}在雙向映射時(shí)，會(huì)相互包含對(duì)方的實(shí)例，相互引用，造成遞歸迭代，堆棧溢出。分析在后端向前端傳遞的時(shí)候會(huì)將數(shù)據(jù)序列化，轉(zhuǎn)為，這時(shí)會(huì)出現(xiàn)循環(huán)引用造成堆棧溢出解決方案解決方法就是在轉(zhuǎn)換時(shí)忽略循環(huán)字段。 問(wèn)題： JPA 在雙向映射時(shí)，會(huì)相互包含對(duì)方的實(shí)例，相互引用，造成遞歸迭代，堆棧溢出（java.lang.StackOverflowError）。 分析: 在后端向前端傳遞的時(shí)候會(huì)將數(shù)據(jù)序列化...
閱讀 1505·2021-11-22 13:52
閱讀 1318·2021-09-29 09:34
閱讀 2718·2021-09-09 11:40
閱讀 3041·2019-08-30 15:54
閱讀 1268·2019-08-30 15:53
閱讀 980·2019-08-30 11:01
閱讀 1369·2019-08-29 17:22
閱讀 1960·2019-08-26 10:57
