218

मैं एक जावा लाइब्रेरी को एक JAR के रूप में पैकेजिंग कर रहा हूं, और java.lang.IncompatibleClassChangeErrorजब मैं इससे तरीके लागू करने की कोशिश कर रहा हूं तो यह कई एस फेंक रहा है। ये त्रुटियां यादृच्छिक रूप से प्रकट होती हैं। इस त्रुटि के कारण किस प्रकार की समस्याएं हो सकती हैं?

— लाश
स्रोत

एक ग्रहण परियोजना में जहां मैं अपाचे एफओपी 1.0 और बारकोड 4 जे का परीक्षण कर रहा था, बारकोड 4 जे के साथ आए अतिरिक्त पुस्तकालय स्पष्ट रूप से उन लोगों को ओवरराइड कर रहे थे जो एफओपी के साथ आए थे (कुछ में उच्च संस्करण संख्याएं थीं)। यह बहुत सावधानी बरतने का मामला है कि आपने अपने निर्माण पथ / वर्गपथ में क्या रखा है।

— विवानी

170

इसका मतलब है कि आपने क्लाइंट कोड को फिर से जमा किए बिना पुस्तकालय में कुछ असंगत द्विआधारी परिवर्तन किए हैं। जावा लैंग्वेज स्पेसिफिकेशन details13 में ऐसे सभी परिवर्तनों का विवरण है, जो सबसे प्रमुख हैं, staticगैर-निजी क्षेत्रों / विधियों को बदलना staticया इसके विपरीत।

नई लाइब्रेरी के विरुद्ध क्लाइंट कोड को पुनःप्राप्त करें, और आपको जाने के लिए अच्छा होना चाहिए।

अद्यतन: यदि आप एक सार्वजनिक पुस्तकालय प्रकाशित करते हैं, तो आपको "द्विआधारी पिछड़े संगतता" के रूप में जाना जाता है जिसे संरक्षित करने के लिए यथासंभव असंगत द्विआधारी परिवर्तन करने से बचना चाहिए। निर्भरता जार को अपडेट करना आदर्श रूप से एप्लिकेशन या बिल्ड को नहीं तोड़ना चाहिए। यदि आपको बाइनरी बैकवर्ड संगतता को तोड़ना है, तो परिवर्तन को जारी करने से पहले प्रमुख संस्करण संख्या (जैसे 1.xy से 2.0.0) को बढ़ाने की सिफारिश की जाती है।

— notnoop
स्रोत

2

किसी कारण से यहाँ डेवलपर्स को एक समस्या हो रही है जहाँ क्लाइंट कोड को फिर से जमा करना समस्या को ठीक नहीं करता है। किसी कारण से अगर वे उस फ़ाइल को संपादित करते हैं जहां यह होता है और त्रुटि को पुन: प्राप्त नहीं होता है, लेकिन प्रोजेक्ट में कहीं और बेतरतीब ढंग से पॉप-अप होगा, जहां लाइब्रेरी संदर्भित है। मैं उत्सुक हूं कि संभवत: यह क्या हो सकता है।

— लाश

5

क्या आपने एक साफ बिल्ड (सभी *.classफ़ाइलों को हटाएं ) और पुन: जमा करने की कोशिश की है? संपादन फ़ाइलों का समान प्रभाव होता है।

— notnoop

कोई गतिशील रूप से उत्पन्न कोड .... जब तक आप एक JSP को ऐसा नहीं मानेंगे। हमने क्लास की फाइलों को हटाने की कोशिश की और इससे मदद नहीं मिली। अजीब बात यह है कि यह सिर्फ मेरे लिए नहीं होता है, लेकिन यह अन्य डेवलपर के लिए होता है।

— लाश 16

2

क्या आप यह सुनिश्चित कर सकते हैं कि जब आप एक स्वच्छ निर्माण करते हैं तो आप उसी जार के खिलाफ संकलित कर रहे हैं जिसके साथ आप चलते हैं?

— नॉटेनोप

क्या 32 बिट या 64 बिट प्लेटफॉर्म के साथ कुछ संबंधित है, मुझे केवल 64 बिट प्लेटफॉर्म में एक त्रुटि मिली।

— काउबोई-पेंग

96

आपकी नई पैक की गई लाइब्रेरी पुराने संस्करण के साथ बैकवर्ड बाइनरी संगत (BC) नहीं है। इस कारण से कुछ लाइब्रेरी क्लाइंट्स जो पुनर्नवीनीकरण नहीं किए गए हैं अपवाद छोड़ सकते हैं।

यह जावा लाइब्रेरी एपीआई में बदलावों की एक पूरी सूची है जो कि java.lang को फेंकने के लिए लाइब्रेरी के पुराने संस्करण के साथ निर्मित क्लाइंट का कारण हो सकता है। यदि वे एक नए (यानी ई.पू. तोड़कर) पर चलते हैं तो असंगत है।

गैर-अंतिम क्षेत्र स्थिर हो जाता है,
गैर-स्थिर क्षेत्र गैर-स्थिर हो जाता है,
क्लास इंटरफ़ेस बन गया,
इंटरफ़ेस कक्षा बन गया,
यदि आप वर्ग / इंटरफ़ेस में एक नया फ़ील्ड जोड़ते हैं (या नया सुपर-क्लास / सुपर-इंटरफ़ेस जोड़ते हैं) तो क्लाइंट क्लास C के सुपर-इंटरफ़ेस से एक स्थिर फ़ील्ड एक जोड़ा फ़ील्ड (उसी नाम से) को विरासत में मिला हो सकता है C का सुपर-क्लास (बहुत दुर्लभ मामला)।

नोट : कई हैं अन्य अपवाद : अन्य असंगत परिवर्तन के कारण NoSuchFieldError , NoSuchMethodError , IllegalAccessError , InstantiationError , VerifyError , NoClassDefFoundError और AbstractMethodError ।

बीसी के बारे में बेहतर पेपर "डेसिंग-बेस्ड जावा-आधारित एपीआई 2: अचीविंग एपीआई बाइनरी कम्पेटिबिलिटी" जिम डे रिविरेस द्वारा लिखा गया है।

ऐसे परिवर्तनों का पता लगाने के लिए कुछ स्वचालित उपकरण भी हैं :

अपने पुस्तकालय के लिए जापी-अनुपालन-चेकर का उपयोग:

japi-compliance-checker OLD.jar NEW.jar

क्लिरर टूल का उपयोग:

java -jar clirr-core-0.6-uber.jar -o OLD.jar -n NEW.jar

सौभाग्य!

— linuxbuild
स्रोत

59

जबकि ये उत्तर सभी सही हैं, समस्या को हल करना अक्सर अधिक कठिन होता है। यह आम तौर पर क्लासपाथ पर एक ही निर्भरता के दो सौम्य रूप से अलग-अलग संस्करणों का परिणाम है, और लगभग हमेशा या तो एक अलग सुपरक्लास के कारण होता है, जो मूल रूप से क्लासपाथ पर होने के खिलाफ संकलित किया गया था या ट्रांज़ेक्टिव क्लोजर के कुछ आयात अलग होने के बावजूद, लेकिन आम तौर पर क्लास में तात्कालिकता और कंस्ट्रक्टर का आह्वान। (सफल क्लास लोडिंग और ctor इनवोकेशन के बाद, आपको मिलेगा NoSuchMethodExceptionया नहीं।)

यदि व्यवहार यादृच्छिक प्रतीत होता है, तो यह संभवत: एक मल्टीथ्रेडेड प्रोग्राम का परिणाम है जो पहले कोड को हिट करने के आधार पर विभिन्न सकर्मक निर्भरता को लोड करता है।

इन्हें हल करने के लिए, -verboseएक तर्क के रूप में वीएम को लॉन्च करने का प्रयास करें , फिर उन कक्षाओं को देखें जो अपवाद होने पर लोड किए जा रहे थे। आपको कुछ आश्चर्यजनक जानकारी देखनी चाहिए। उदाहरण के लिए, एक ही निर्भरता और संस्करणों की कई प्रतियाँ होने की आप कभी उम्मीद नहीं करते थे या यदि आप जानते थे कि वे शामिल किए जा रहे हैं तो स्वीकार कर लिया होगा।

मावेन के साथ डुप्लिकेट जार को हल करना मावेन -डिपेंडेंसी-प्लगइन और मावेन -एनफोर्सर-प्लगइन के संयोजन के साथ मावेन (या एसबीटी की डिपेंडेंसी ग्राफ प्लगइन) के संयोजन के साथ सबसे अच्छा किया जाता है , फिर उन जारों को अपने टॉप-लेवल पीओएम के एक अनुभाग में या आयातित निर्भरता के रूप में जोड़ दिया जाता है। एसबीटी में तत्व (उन निर्भरता को दूर करने के लिए)।

सौभाग्य!

— ब्रायन टॉपिंग
स्रोत

5

क्रिया तर्क ने मुझे इंगित करने में मदद की कि कौन से जार समस्याएं दे रहे थे। धन्यवाद

— विराट Kadaru

6

मैंने यह भी पता लगाया है कि, JNI का उपयोग करते समय, C ++ से जावा विधि का उपयोग करते हुए, यदि आप गलत तरीके से आह्वान किए गए जावा विधि में पैरामीटर पास करते हैं, तो आपको यह त्रुटि तब मिलेगी जब आप कॉल की गई विधि के अंदर मापदंडों का उपयोग करने का प्रयास करेंगे (क्योंकि वे सही प्रकार नहीं होगा)। मुझे शुरू में इस बात से ऐतराज़ था कि जेएनआई आपके लिए क्लास सिग्नेचर चेकिंग के एक हिस्से के रूप में आपके लिए यह जाँच नहीं करता है जब आप विधि लागू करते हैं, लेकिन मुझे लगता है कि वे इस तरह की जाँच नहीं करते हैं क्योंकि आप पॉलीमॉर्फिक पैरामीटर पारित कर सकते हैं और उन्हें करना होगा आप जानते हैं कि आप क्या कर रहे हैं।

उदाहरण C ++ JNI कोड:

void invokeFooDoSomething() {
    jobject javaFred = FredFactory::getFred(); // Get a Fred jobject
    jobject javaFoo = FooFactory::getFoo(); // Get a Foo jobject
    jobject javaBar = FooFactory::getBar(); // Get a Bar jobject
    jmethodID methodID = getDoSomethingMethodId() // Get the JNI Method ID


    jniEnv->CallVoidMethod(javaFoo,
                           methodID,
                           javaFred, // Woops!  I switched the Fred and Bar parameters!
                           javaBar);

    // << Insert error handling code here to discover the JNI Exception >>
    //  ... This is where the IncompatibleClassChangeError will show up.
}

उदाहरण जावा कोड:

class Bar { ... }

class Fred {
    public int size() { ... }
} 

class Foo {
    public void doSomething(Fred aFred, Bar anotherObject) {
        if (name.size() > 0) { // Will throw a cryptic java.lang.IncompatibleClassChangeError
            // Do some stuff...
        }
    }
}

— ओगरे भजन 33
स्रोत

1

संकेत के लिए धन्यवाद। मुझे एक ही समस्या थी जब गलत तरीके (आपूर्ति) के साथ जावा विधि को कॉल करना।

— sstn

5

मेरे पास एक ही मुद्दा था, और बाद में मुझे पता चला कि मैं जावा संस्करण 1.4 पर आवेदन चला रहा हूं, जबकि आवेदन 6 संस्करण पर संकलित है।

दरअसल, इसका कारण डुप्लिकेट लाइब्रेरी था, एक क्लासपाथ के भीतर स्थित है और दूसरे को जार फ़ाइल के अंदर शामिल किया गया है जो क्लासपाथ के भीतर स्थित है।

— Eng.Fouad
स्रोत

आप इसकी तह तक कैसे पहुंचे? मुझे यकीन है कि मैं भी इसी तरह की समस्या है, लेकिन एक सुराग नहीं है कि कैसे निर्भरता पुस्तकालय का पता लगाने के लिए दोहराया जा रहा है।

— beterthanlife

@beterthanlife एक स्क्रिप्ट लिखती है, जो डुप्लिकेटेड क्लासेस (उनके पूर्ण-योग्य नाम से

— खोजती है

ठीक है, NetBeans और मावेन-शेड का उपयोग करते हुए मुझे लगता है कि मैं उन सभी वर्गों को देख सकता हूं जिन्हें नकल किया जा रहा है और जार फाइलें जो वे निवास करते हैं। इनमें से कई जार फाइलें जो मैंने सीधे अपने pom.xml में संदर्भित नहीं की हैं, इसलिए मुझे लगता है कि उन्हें होना चाहिए। मेरे आश्रितों द्वारा शामिल किया जा रहा है। क्या यह पता लगाने का एक आसान तरीका है कि निर्भरता की पोम फ़ाइल में से प्रत्येक के माध्यम से जाने के बिना, उन पर निर्भरता किसमें शामिल है? (कृपया मेरी महानता को क्षमा करें, मैं एक जावा कुंवारी हूँ!)

— beterthanlife

@beterthanlife बेहतर है कि :) के बारे में एक नया सवाल पूछें :)

— Eng.Fouad

मुझे ढाल निर्भरता ग्राफ (./gradlew: <name>: निर्भरता) को देखकर एक डुप्लिकेट जार मिला। इसलिए मुझे अपराधी का पता चला जिसने परियोजना में पुराने संस्करण को हटा दिया।

— nyx

1

एक और स्थिति जहां यह त्रुटि दिखाई दे सकती है वह एम्मा कोड कवरेज के साथ है।

यह तब होता है जब एक अंतरफलक के लिए एक वस्तु प्रदान करते हैं। मुझे लगता है कि इस वस्तु के साधन के साथ कुछ करना है और बाइनरी संगत नहीं है।

http://sourceforge.net/tracker/?func=detail&aid=3178921&group_id=177969&atid=883351

सौभाग्य से यह समस्या कोबर्टुरा के साथ नहीं होती है, इसलिए मैंने अपने pom.xml के रिपोर्टिंग प्लग इन में कोबर्टुरा-मावेन-प्लगइन जोड़ा है

— stivlo
स्रोत

1

मैंने इस मुद्दे का सामना किया है जबकि अनिर्दिष्ट और कांच के बने पदार्थ के साथ एक युद्ध को फिर से तैयार करना। मेरी कक्षा की संरचना इस प्रकार थी,

public interface A{
}

public class AImpl implements A{
}

और इसे बदल दिया गया था

public abstract class A{
}

public class AImpl extends A{
}

डोमेन को रोकने और पुनः आरंभ करने के बाद, इसने ठीक काम किया। मैं ग्लासफिश 3.1.43 का उपयोग कर रहा था

— Nerrve
स्रोत

1

मेरे पास एक वेब एप्लिकेशन है जो मेरे लोकल मशीन के टॉमकैट (8.0.20) पर पूरी तरह से ठीक है। हालाँकि, जब मैंने इसे qa वातावरण (tomcat - 8.0.20) में डाला, तो यह मुझे IncompatibleClassChangeError देता रहा और यह शिकायत कर रहा था कि मैं इंटरफ़ेस पर विस्तार कर रहा हूं। इस इंटरफ़ेस को एक अमूर्त वर्ग में बदल दिया गया था। और मैंने माता-पिता और बच्चे की कक्षाओं को संकलित किया और फिर भी मैं एक ही मुद्दा प्राप्त करता रहा। अंत में, मैं डिबग करना चाहता था, इसलिए, मैंने माता-पिता पर संस्करण को x.0.1-SNAPSHOT में बदल दिया और फिर सब कुछ संकलित किया और अब यह काम कर रहा है। यदि कोई व्यक्ति यहां दिए गए उत्तरों का पालन करने के बाद भी समस्या से जूझ रहा है, तो कृपया सुनिश्चित करें कि आपके pom.xml में संस्करण भी सही हैं। यह देखने के लिए संस्करण बदलें कि क्या काम करता है। यदि ऐसा है, तो संस्करण की समस्या को ठीक करें।

— जोबिन थॉमस
स्रोत

1

मेरा जवाब, मुझे विश्वास है, इंटेलीज विशिष्ट होगा।

मैंने साफ सुथरा बनाया था, यहां तक कि "आउट" और "टारगेट" डायर को मैन्युअल रूप से हटाने के लिए भी जा रहा था। इंटेलीज में एक "अमान्य कैश और पुनरारंभ" है, जो कभी-कभी अजीब त्रुटियों को साफ करता है। इस बार काम नहीं किया। निर्भरता संस्करण सभी परियोजना सेटिंग्स में सही दिखे-> मॉड्यूल मेनू।

अंतिम जवाब अपने स्थानीय मावेन रेपो से मेरी समस्या निर्भरता को मैन्युअल रूप से हटाने के लिए था। बाउंसिलकैस्टल का एक पुराना संस्करण अपराधी था (मुझे पता था कि मेरे पास अभी संस्करण बदल गए हैं और यह समस्या होगी) और यद्यपि पुराने संस्करण ने दिखाया कि क्या बनाया जा रहा है, जहां उसने मेरी समस्या को हल किया। मैं intellij संस्करण 14 का उपयोग कर रहा था और फिर इस प्रक्रिया के दौरान 15 में अपग्रेड किया गया।

— डेविड निकर्सन
स्रोत

1

मेरे मामले में, मैं इस तरह से इस त्रुटि में भाग गया। pom.xmlमेरी परियोजना की दो निर्भरताएँ Aऔर परिभाषित की गईं B। और दोनों Aऔर Bएक ही विरूपण साक्ष्य पर निर्भरता (इसे कॉल करें C) लेकिन इसके विभिन्न संस्करण ( C.1और C.2)। जब ऐसा होता है, Cमावेन में प्रत्येक वर्ग के लिए केवल दो संस्करणों में से एक वर्ग का एक संस्करण का चयन कर सकते हैं (एक यूबर-जार का निर्माण करते समय )। यह अपने निर्भरता मध्यस्थता नियमों के आधार पर "निकटतम" संस्करण का चयन करेगा और चेतावनी को आउटपुट करेगा "हमारे पास एक डुप्लिकेट क्लास है ..." यदि संस्करणों के बीच एक विधि / वर्ग हस्ताक्षर बदलता है, तो यह एक java.lang.IncompatibleClassChangeErrorअपवाद पैदा कर सकता है यदि गलत संस्करण है रनटाइम पर उपयोग किया जाता है।

उन्नत: अगर Aकी v1 का उपयोग करना चाहिए Cऔर Bके वी 2 का उपयोग करना चाहिए C, तो हम चाहिए स्थानांतरित C में Aऔर Bसे बचने के वर्ग संघर्ष करने के poms (हम एक नकली वर्ग चेतावनी है) जब अंतिम परियोजना है कि दोनों पर निर्भर करता है के निर्माण Aऔर B।

— मॉर्फियस
स्रोत

1

मेरे मामले में त्रुटि तब सामने आई जब मैंने com.nimbusdsअपने आवेदन में पुस्तकालय को जोड़ा Websphere 8.5।
निम्न अपवाद हुआ:

इसके कारण: java.lang.IncompatibleClassChangeError: org.objectweb.asm.nnotationVisitor

समाधान को पुस्तकालय से asm जार को बाहर करना था:

<dependency>
    <groupId>com.nimbusds</groupId>
    <artifactId>nimbus-jose-jwt</artifactId>
    <version>5.1</version>
    <exclusions>
        <exclusion>
            <artifactId>asm</artifactId>
            <groupId>org.ow2.asm</groupId>
        </exclusion>
    </exclusions>
</dependency>

— अमाइन
स्रोत

0

कृपया जाँचें कि क्या आपके कोड में दो मॉड्यूल परियोजनाएँ हैं जिनमें समान वर्ग नाम और संकुल परिभाषा है। उदाहरण के लिए ऐसा हो सकता है यदि कोई पिछले कार्यान्वयन के आधार पर इंटरफ़ेस के नए कार्यान्वयन को बनाने के लिए कॉपी-पेस्ट का उपयोग करता है।

— denu
स्रोत

0

यदि यह इस त्रुटि की संभावित घटनाओं का रिकॉर्ड है तो:

मुझे बस WAS (8.5.0.1) पर, वसंत के लोडिंग (3.1.1_release) के सीएक्सएफ (2.6.0) लोडिंग के दौरान यह त्रुटि मिली, जहां एक बीनइनस्टेंटिएशनएक्सएक्सएक्स ने एक सीएक्सएफ एक्सटेंशनएक्सएक्सएक्स को रोल किया, जिसमें एक असंगत क्लैसचेंजइज़रएयर को रोल किया। निम्नलिखित स्निपेट स्टैक ट्रेस का सार दिखाता है:

Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.bus.spring.SpringBus]: Constructor threw exception; nested exception is org.apache.cxf.bus.extension.ExtensionException
            at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:162)
            at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:76)
            at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:990)
            ... 116 more
Caused by: org.apache.cxf.bus.extension.ExtensionException
            at org.apache.cxf.bus.extension.Extension.tryClass(Extension.java:167)
            at org.apache.cxf.bus.extension.Extension.getClassObject(Extension.java:179)
            at org.apache.cxf.bus.extension.ExtensionManagerImpl.activateAllByType(ExtensionManagerImpl.java:138)
            at org.apache.cxf.bus.extension.ExtensionManagerBus.<init>(ExtensionManagerBus.java:131)
            [etc...]
            at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:147)
            ... 118 more

Caused by: java.lang.IncompatibleClassChangeError: 
org.apache.neethi.AssertionBuilderFactory
            at java.lang.ClassLoader.defineClassImpl(Native Method)
            at java.lang.ClassLoader.defineClass(ClassLoader.java:284)
            [etc...]
            at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:586)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:658)
            at org.apache.cxf.bus.extension.Extension.tryClass(Extension.java:163)
            ... 128 more

इस मामले में, समाधान मेरी युद्ध फ़ाइल में मॉड्यूल के क्लासपैथ क्रम को बदलना था। यही है, के तहत WAS कंसोल में युद्ध एप्लिकेशन खोलें और क्लाइंट मॉड्यूल का चयन करें। मॉड्यूल कॉन्फ़िगरेशन में, "मूल अंतिम" होने के लिए कक्षा-लोडिंग सेट करें।

यह WAS कंसोल में पाया जाता है:

आवेदन पत्र -> आवेदन के प्रकार -> वेबस्फेयर एंटरप्राइज एप्लीकेशन
अपने आवेदन (युद्ध) का प्रतिनिधित्व करने वाले लिंक पर क्लिक करें
"मॉड्यूल" अनुभाग के तहत "मॉड्यूल प्रबंधित करें" पर क्लिक करें
अंतर्निहित मॉड्यूल के लिए लिंक पर क्लिक करें
"क्लास लोडर ऑर्डर" को "(मूल अंतिम)" बदलें।

— wmorrison365
स्रोत

0

बहुत समय जलने के बाद एक और परिदृश्य का दस्तावेजीकरण।

सुनिश्चित करें कि आपके पास एक निर्भरता जार नहीं है जिस पर एक EJB एनोटेशन के साथ एक वर्ग है।

हमारे पास एक सामान्य जार फ़ाइल थी जिसमें एक @localएनोटेशन था। उस वर्ग को बाद में उस आम परियोजना से हटा दिया गया और हमारी मुख्य ejb जार परियोजना में बदल दिया गया। हमारे ejb जार और हमारे आम जार दोनों को एक कान के भीतर बांधा जाता है। हमारे सामान्य जार निर्भरता का संस्करण अपडेट नहीं किया गया था। इस प्रकार 2 कक्षाएं असंगत परिवर्तन के साथ कुछ होने की कोशिश कर रही हैं।

— Snekse
स्रोत

0

उपरोक्त सभी - किसी भी कारण से मैं कुछ बड़ा रिफ्लेक्टर कर रहा था और इसे प्राप्त करना शुरू कर रहा था। मैंने उस पैकेज का नाम बदल दिया, जिसमें मेरा इंटरफ़ेस था और उसने इसे साफ़ कर दिया। उम्मीद है की वो मदद करदे।

— bsautner
स्रोत

0

किसी कारण से JNI का उपयोग करते समय और कॉल करते समय जॉबजेक्ट के बजाय jclass तर्क पारित करने के लिए समान अपवाद भी फेंका जाता है Call*Method()।

यह Ogre Psalm33 के उत्तर के समान है।

void example(JNIEnv *env, jobject inJavaList) {
    jclass class_List = env->FindClass("java/util/List");

    jmethodID method_size = env->GetMethodID(class_List, "size", "()I");
    long size = env->CallIntMethod(class_List, method_size); // should be passing 'inJavaList' instead of 'class_List'

    std::cout << "LIST SIZE " << size << std::endl;
}

मुझे पता है कि इस सवाल का जवाब देने में थोड़ा देर हो गई है, लेकिन यह पूछे जाने के 5 साल बाद है, लेकिन जब java.lang.IncompatibleClassChangeErrorमैं इस विशेष मामले का दस्तावेजीकरण करना चाहता था , तो यह शीर्ष हिट में से एक है ।

— एरिक ओबमुह्लनर
स्रोत

0

मेरे 2 सेंट जोड़ना। यदि आप स्काला और एसबीटी और स्काला-लॉगिंग का उपयोग निर्भरता के रूप में कर रहे हैं, तो ऐसा हो सकता है क्योंकि स्कैला-लॉगिंग के पुराने संस्करण का नाम scala-log-api.So था; अनिवार्य रूप से निर्भरता के रिज़ॉल्यूशन भिन्न के कारण नहीं होते हैं स्काला एप्लिकेशन लॉन्च करते समय रनटाइम त्रुटियों के लिए नाम।

— सौरभ
स्रोत

0

इस समस्या का एक अतिरिक्त कारण, यदि आपके पास है Instant Run Android Studio के लिए सक्षम किया है।

जोड़

यदि आप पाते हैं कि आपको यह त्रुटि मिल रही है, तो बंद करें Instant Run।

Android स्टूडियो मुख्य सेटिंग्स
निर्माण, निष्पादन, परिनियोजन
तुरंत भागो
"तत्काल रन सक्षम करें ..." पर क्लिक करें

क्यों

Instant Runविकास के दौरान बड़ी संख्या में चीजों को संशोधित करता है, जिससे यह आपके चलने वाले ऐप को अपडेट प्रदान करने के लिए तेज हो। इसलिए तुरंत चला। जब यह काम करता है, तो यह वास्तव में उपयोगी है। हालांकि, जब इस तरह के एक मुद्दे पर हमला होता है, तो सबसे अच्छी बात यह है कि Instant Runएंड्रॉइड स्टूडियो रिलीज के अगले संस्करण तक बंद कर दिया जाए ।

— Knossos
स्रोत

Java.lang.IncompatibleClassChangeError क्या कारण है?

जोड़

क्यों