2012-01-24 13 views
12

मैं JDK और JRE स्रोत और बाइनरी अनुकूलता (जैसे this और this), लेकिन निम्न स्थिति के बारे में निश्चित नहीं बारे में कुछ जान:JDK, JRE एक जार अनुकूलता

पर विचार करें मैं एक आवेदन जो JDK5 का उपयोग कर संकलित किया गया है है और जेआरई 6 पर चलता है। यह कुछ पुस्तकालयों (जार) का उपयोग करता है जिन्हें जेडीके 5 का उपयोग करके भी संकलित किया जाता है।

अब मैं जेडीके 6 का उपयोग करके अपना आवेदन संकलित करना चाहता हूं। ऐसे मामले में रनटाइम में क्या नई समस्याएं उत्पन्न हो सकती हैं (विशेष रूप से, "पुराने" जार के साथ संगतता में)? क्या मुझे आवेदन पूरी तरह से रीस्टेट करना चाहिए (प्रत्येक लाइब्रेरी को स्पर्श करें) या वादा किए गए जेडीके/जेआरई संगतता पर भरोसा कर सकते हैं?

+0

संभावित डुप्लिकेट [क्या जावा संस्करणों के बीच पिछड़े असंगतताओं के कोई विशिष्ट उदाहरण हैं?] (Http://stackoverflow.com/questions/1654923/are-there-any- विशिष्ट-examples-of-backward-incompatibilities-between -जावा-बनाम) –

उत्तर

2

जब तक कि आपने अपना कोड नहीं बदला है और नई जावा 6 सुविधाओं को जोड़ा नहीं है, तो कोई समस्या नहीं होनी चाहिए। अन्य जारों के संबंध में कोई समस्या नहीं होनी चाहिए। जेडीके हमेशा पिछड़ा संगतता बनाए रखता है।

+0

"_JDK हमेशा पिछड़ा संगतता बनाए रखता है_" कम से कम भ्रामक: ओपी को टिप्पणियों में लिंक किए गए प्रश्न को देखें। – Alberto

2

संगतता ज्यादातर काम करता है। मैं आपके लिए चेतावनियों से अलग होने के लिए किसी भी मुद्दे की अपेक्षा नहीं करूंगा उदाहरण के लिए जेनेरिक का उपयोग नहीं। हो सकता है कि कुछ मुश्किल से इस्तेमाल किए गए एपीआई को बहिष्कृत कर दिया गया हो, लेकिन मुझे लगता है कि वे जगह पर छोड़े गए थे, जिन्हें बस बहिष्कृत के रूप में चिह्नित किया गया था।

बस इसे आजमाएं, अगर यह आपको संकलित करता है ठीक होना चाहिए।

जावा का एक प्रमुख डिज़ाइन पहलू - दुर्भाग्य से - पूर्ण पिछड़ा संगतता है।

बहुत कम अपवाद हैं जहां पिछड़ा संगतता संरक्षित नहीं थी; सबसे प्रमुख रूप से ग्रहण का सामना करना पड़ा जब सॉर्टिंग एल्गोरिदम स्थिर से एक गैर-स्थिर प्रकार एल्गोरिदम में बदल दिया गया था (ऑब्जेक्ट्स का क्रम जो समान रूप से संरक्षित नहीं था); लेकिन यह जावा विनिर्देश का हिस्सा कभी नहीं था, लेकिन ग्रहण में एक बग था।

यह दुर्भाग्यपूर्ण है, क्योंकि कुछ खराब विकल्प थे जिन्हें अब बदला नहीं जा सकता है। Iterator को एपीआई में remove() फ़ंक्शन नहीं होना चाहिए था, Vector सिंक्रनाइज़ नहीं किया जाना चाहिए था (ArrayList अब हल करके हल किया जाना चाहिए), StringBuffer सिंक्रनाइज़ नहीं किया जाना चाहिए था, इसलिए StringBuilderString शायद एक इंटरफ़ेस होना चाहिए, कक्षा नहीं, उदाहरण के लिए अनुमति देना 8-बिट स्ट्रिंग्स, 32-बिट स्ट्रिंग्स - CharSequence बेहतर स्ट्रिंग इंटरफ़ेस है, लेकिन बहुत से तरीके CharSequence स्वीकार नहीं करते हैं और String लौटने की आवश्यकता होती है। Observable एक इंटरफ़ेस भी होना चाहिए: आप इस API के साथ उप-वर्ग को देखने योग्य नहीं बना सकते हैं। कुछ नाम है। लेकिन पिछली संगतता की वजह से, इन्हें अब तक जेडीके मॉड्यूलरलाइजेशन तक तय नहीं किया जा सकता है (जिस बिंदु पर कुछ कम से कम एक डोनोट्यूज मॉड्यूल में गायब हो सकते हैं ...)।

बेशक आप पहले से ही इकाई के हजारों होना चाहिए परीक्षण आप नए JDK के साथ परीक्षण करने का ... :-)

+0

और आपको भी संकलित इकाई निष्पादित करने की कोशिश करनी चाहिए, अगर यह निष्पादन योग्य है .. इच्छित जावा वीएम का उपयोग करके जो उत्पादन में प्रयुक्त होता है। इस तरह, मुझे लगता है, मैं संगतता की जांच करता हूं। – Victor

+0

निष्पक्ष होने के लिए, "_ बस इसे आज़माएं, अगर यह अनुपालन करता है [एसआईसी] आपको ठीक होना चाहिए" मुझे बहुत जोखिम भरा दृष्टिकोण की तरह लगता है: मुझे अभी भी रनटाइम पर अप्रत्याशित समस्याओं का डर होगा। तो -1 (कि मैं जवाब संपादित किए बिना पूर्ववत नहीं कर सकता) अभी भी है। – Alberto

+0

जावा में उच्च पिछड़ा संगतता आवश्यकताएं हैं। वे भी एक व्यापक परीक्षण सूट माना जाता है। तो जब तक कि वे कुछ बदसूरत हैक वापस नहीं करते हैं, तब भी कोड संगत होना चाहिए; क्योंकि सभी विधियों को अभी भी वहां होना चाहिए, जैसा कि वे थे। और यदि उन्होंने परीक्षण नहीं लिखा ... –

9

आम तौर पर कोई समस्या नहीं उत्पन्न होता है तो आप के लिए JDK6 का संकलक विकल्प सेट करता है, तो 1.5 स्रोत संगतता का उपयोग करें। हालांकि कभी-कभी यह हमेशा सत्य नहीं होता

मुझे 1.5 संकलक के साथ 1.4 कोड संकलित करते समय एक बार याद है (1.4 संगतता का उपयोग करके)। जार जहां ठीक है (1.4 बाइनरी स्तर) लेकिन एक मजेदार रूपांतरण के कारण एप्लिकेशन क्रैश हो गया।

हमने एक बिगडिसीमल संख्या का उपयोग कन्स्ट्रक्टर को तर्क के रूप में एक पूर्णांक को पारित किया। 1.4 version में केवल double से एक निर्माता था लेकिन 1.5 version दोनों में int और double रचनाकार थे। तो 1.4 कंपाइलर के साथ संकलन करते समय स्वचालित रूपांतरण int से double पर किया गया, लेकिन 1.5 कंपाइलर के साथ यह जांच किया गया कि int कन्स्ट्रक्टर अस्तित्व में था और उस रूपांतरण को महसूस नहीं किया। फिर 1.4 जेआरई पर सही बाइनरी संगत कोड का उपयोग करते समय प्रोग्राम NoSuchMethodException के साथ दुर्घटनाग्रस्त हो गया।

मुझे यह मानना ​​है कि यह एक अजीब मामला था, लेकिन यह उन मामलों में से एक है जहां तर्क काम नहीं करता है। तो मेरी सलाह यह है कि यदि आप जेआरई के पुराने संस्करणों के लिए संकलन करने की योजना बनाते हैं तो जब भी संभव हो तो लक्षित संस्करण जेडीके का उपयोग करने का प्रयास करें।

+0

@Igor, जेडीके संगतता दस्तावेज़ से: 7. जावा एसई 6 उचित रूप से अवैध कास्ट कास्ट कार्यान्वयन जावा भाषा विशिष्टता के लिए अधिक बारीकी से पालन करता है। आम तौर पर, इसका मतलब है कि जावैक अधिक कार्यक्रम स्वीकार करेगा। हालांकि, कुछ दुर्लभ मामलों में, जावैक अब पहले स्वीकृत, फिर भी गलत कार्यक्रमों को अस्वीकार कर सकता है। http://www.oracle.com/technetwork/java/javase/compatibility-137541.html#incompatibilities दरअसल मेरे पास 1 ऐसा समस्या है। – alexsmail

+1

बेशक उन्होंने संगतता के मुद्दों में सुधार किया होगा। मेरा मामला 1.4-> 1.5 माइग्रेशन था। और 1.3-> 1.4 और भी बदतर था (1.3 बुरी तरह टूटा हुआ था) –

+0

इस मुद्दे को पुनर्जीवित करने के लिए खेद है - मैंने सवाल को गलत तरीके से पढ़ा और फिर से पढ़ने के बाद मुझे अपने वोट को पूर्ववत करने के लिए मजबूर होना पड़ा - मुझे यकीन नहीं है कि आपका वर्णित स्थिति ओपी के मेल खाता है। क्या आप केवल स्रोत संगतता ('-सोर्स'), या लक्ष्य ('-targetarget') संगतता के बारे में बात कर रहे हैं? और आपने जेआरई 1.4 में चलाने के लिए जेडीके 5 के साथ संकलित किया है। ओपी जेआरई 6 के लिए जेडीके 5 के साथ संकलित करता है, और जेआरई 6 के लिए जेडीके 6 के साथ संकलित करने के लिए अपग्रेड करता है। आपकी स्थिति बहुत अलग दिखती है। लेकिन अगर आपको याद नहीं है, वैसे भी इसे भूल जाओ (मैं पहले से ही उभरा हूं, और यह अभी भी दूसरों के लिए चेतावनी के रूप में काम कर सकता है) – Alberto

संबंधित मुद्दे