जावा 9 उन लोगों के लिए ट्यूटोरियल जिन्हें विरासत कोड के साथ काम करना है

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

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

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

इसलिए, जैसे ही डेवलपर एक नए अवसर की कोशिश करने जा रहा है, उसे समस्याओं का सामना करना पड़ रहा है। क्या आप अपने कोड में डिफ़ॉल्ट इंटरफ़ेस विधियों का उपयोग करेंगे? शायद - यदि आप भाग्यशाली हैं और आपके आवेदन को जावा 7 या निम्न के साथ सहभागिता करने की आवश्यकता नहीं है। बहु-थ्रेडेड अनुप्रयोग में छद्म यादृच्छिक संख्या उत्पन्न करने के लिए java.util.concurrent.ThreadLocalRandom वर्ग का उपयोग करना चाहते हैं? यदि आपका एप्लिकेशन उसी समय जावा 6, 7, 8 या 9 पर चलना चाहिए तो यह काम नहीं करेगा।

नई रिलीज के साथ, विरासत कोड का समर्थन करने वाले डेवलपर्स ऐसा महसूस करते हैं कि बच्चे एक पेस्ट्री शॉप की खिड़की पर घूरने के लिए मजबूर हैं। उन्हें अंदर जाने की अनुमति नहीं है, इसलिए उनकी नियति निराशा और हताशा है।

तो, विरासत कोड समर्थन में शामिल प्रोग्रामर के लिए जावा 9 की नई रिलीज में कुछ है? कुछ ऐसा जो उनके जीवन को आसान बना सके? सौभाग्य से, हाँ।

विरासत कोड के समर्थन के साथ जो किया जाना था वह जावा 9 की उपस्थिति है

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

उदाहरण के लिए, आप देर से बाध्यकारी लागू कर सकते हैं यदि आप नए एपीआई का उपयोग करना चाहते हैं जब आपके आवेदन को जावा के पुराने संस्करणों के साथ काम करने की आवश्यकता होती है जो इस एपीआई का समर्थन नहीं करते हैं। मान लें कि आप जावा 8 में शुरू की गई java.util.stream.LongStream क्लास का उपयोग करना चाहते हैं, और आप इस वर्ग के anyMatch(LongPredicate) पद्धति का उपयोग करना चाहते हैं, लेकिन एप्लिकेशन को जावा 7 के साथ संगत होना चाहिए। आप एक सहायक वर्ग बना सकते हैं, जैसे:

 public classLongStreamHelper { private static Class longStreamClass; private static Class longPredicateClass; private static Method anyMatchMethod; static { try { longStreamClass = Class.forName("java.util.stream.LongStream"); longPredicateClass = Class.forName("java.util.function.LongPredicate"); anyMatchMethod = longStreamClass.getMethod("anyMatch", longPredicateClass): } catch (ClassNotFoundException e) { longStreamClass = null; longPredicateClass = null; anyMatchMethod = null } catch (NoSuchMethodException e) { longStreamClass = null; longPredicateClass = null; anyMatchMethod = null; } public static boolean anyMatch(Object theLongStream, Object thePredicate) throws NotImplementedException { if (longStreamClass == null) throw new NotImplementedException(); try { Boolean result = (Boolean) anyMatchMethod.invoke(theLongStream, thePredicate); return result.booleanValue(); } catch (Throwable e) { // lots of potential exceptions to handle. Let's simplify. throw new NotImplementedException(); } } } 

इस ऑपरेशन को सरल बनाने के तरीके हैं, या इसे अधिक सामान्य, या अधिक प्रभावी बनाने के लिए - आपको विचार मिला।

theLongStream.anyMatch(thePredicate) को कॉल करने के बजाय, जैसा कि आप जावा 8 में करेंगे, आप जावा के किसी भी संस्करण में LongStreamHelper.anyMatch(theLongStream, thePredicate) को कॉल कर सकते हैं। यदि आप जावा 8 के साथ काम कर रहे हैं, तो यह काम करेगा, लेकिन अगर जावा 7 के साथ, तो प्रोग्राम NotImplementedException को फेंक NotImplementedException ।

यह बदसूरत क्यों है? क्योंकि यदि आप कई एपीआई (वास्तव में, अब भी, एकल एपीआई के साथ, यह पहले से ही असुविधाजनक है) तक पहुँचने की आवश्यकता है, तो कोड अत्यधिक जटिल हो सकता है। इसके अलावा, यह अभ्यास टाइप-सुरक्षित नहीं है, क्योंकि कोड सीधे LongStream या LongPredicate उल्लेख नहीं कर सकता है। अंत में, यह अभ्यास बहुत कम कुशल है, प्रतिबिंब के ओवरहेड के कारण, साथ ही अतिरिक्त try-catch ब्लॉक भी। इसलिए, हालांकि यह इस तरह से किया जा सकता है, यह बहुत दिलचस्प नहीं है, और लापरवाही के कारण त्रुटियों से भरा है।

हां, आप नए एपीआई तक पहुंच सकते हैं, और एक ही समय में आपका कोड पिछड़े संगतता को बनाए रखता है, लेकिन आप नए भाषा निर्माणों के साथ सफल नहीं होंगे। उदाहरण के लिए, मान लें कि हमें कोड में लैम्ब्डा अभिव्यक्ति का उपयोग करने की आवश्यकता है जो कि पिछड़े संगत बने रहें और जावा 7 में काम करें। आप भाग्य से बाहर हैं। जावा संकलक आपको लक्ष्य से ऊपर स्रोत कोड का एक संस्करण निर्दिष्ट करने की अनुमति नहीं देगा। इसलिए, यदि आप स्रोत कोड के अनुपालन स्तर को 1.8 (यानी, जावा 8) पर सेट करते हैं, और लक्ष्य अनुपालन स्तर 1.7 (जावा 7) है, तो संकलक आपको अनुमति नहीं देगा।

मल्टी-वर्जन JAR फाइलें आपकी मदद करेंगी

अभी हाल ही में, एक और बढ़िया अवसर नवीनतम जावा सुविधाओं का उपयोग करने के लिए प्रकट हुआ है, जबकि अनुप्रयोगों को जावा के पुराने संस्करणों के साथ काम करने की अनुमति देता है, जहां ऐसे अनुप्रयोगों का समर्थन नहीं किया गया था। जावा 9 में, यह सुविधा नए एपीआई और नए जावा भाषा निर्माण दोनों के लिए प्रदान की गई है: हम बहु-संस्करण JAR फ़ाइलों के बारे में बात कर रहे हैं।

बहु-संस्करण JAR फाइलें लगभग अच्छी पुरानी JAR फ़ाइलों से भिन्न नहीं होती हैं, लेकिन एक महत्वपूर्ण चेतावनी के साथ: नई JAR फ़ाइलों में एक नया "आला" सामने आया है, जहाँ आप उन कक्षाओं को लिख सकते हैं जो नवीनतम Java 9 सुविधाओं का उपयोग करते हैं। यदि आप जावा 9 पर काम करते हैं, तो। JVM इस "आला" को खोजेगा, इसमें से कक्षाओं का उपयोग करेगा और JAR फ़ाइल के मुख्य भाग से समान नाम की कक्षाओं को अनदेखा करेगा।

हालांकि, जब जावा 8 या उससे कम के साथ काम करते हैं, तो JVM को इस "आला" के अस्तित्व के बारे में पता नहीं होता है। वह इसे अनदेखा करती है और JAR फ़ाइल के मुख्य भाग से कक्षाओं का उपयोग करती है। जावा 10 की रिलीज़ के साथ, एक नया समान "आला" उन कक्षाओं के लिए दिखाई देगा जो जावा 10 और इतने पर सबसे प्रासंगिक सुविधाओं का उपयोग करते हैं।

जेईपी 238 में , जावा विकास के लिए एक प्रस्ताव, जिसमें रेवेरस जेएआर फाइलों का वर्णन है, एक सरल उदाहरण प्रदान किया गया है। मान लीजिए कि हमारे पास एक जावा फ़ाइल है जो चार कक्षाओं में जावा 8 या निम्न में चल रही है:

 JAR root - A.class - B.class - C.class - D.class 

अब कल्पना करें कि जावा 9 के रिलीज के बाद, हम ए और बी को फिर से लिखते हैं ताकि वे जावा 9 के लिए विशिष्ट नई सुविधाओं का उपयोग कर सकें। फिर जावा 10 बाहर आता है, और हम कक्षा ए को फिर से लिखते हैं ताकि यह जावा 10 की नई सुविधाओं का उपयोग कर सके। एप्लिकेशन को जावा 8 के साथ अभी भी ठीक काम करना चाहिए। नई बहु-संस्करण JAR फ़ाइल इस तरह दिखती है:

 JAR root - A.class - B.class - C.class - D.class - META-INF Versions - 9 - A.class - B.class - 10 - A.class 

JAR फ़ाइल ने न केवल एक नई संरचना प्राप्त कर ली है; अब उनके प्रदर्शन में यह संकेत दिया गया है कि यह फ़ाइल बहु-संस्करण है।

जब आप जावा 8 JVM में इस JAR फ़ाइल को चलाते हैं, तो यह \META-INF\Versions अनुभाग को अनदेखा कर देता है क्योंकि यह भी इस पर संदेह नहीं करता है या इसे नहीं देखता है। केवल मूल कक्षाएं A, B, C और D का उपयोग किया जाता है।

जावा 9 के तहत चलने पर, \META-INF\Versions\9 में स्थित वर्गों का उपयोग किया जाता है, इसके अलावा, वे मूल कक्षाओं ए और बी के बजाय उपयोग किए जाते हैं, लेकिन \META-INF\Versions\10 में वर्गों \META-INF\Versions\10 अनदेखा किया \META-INF\Versions\10 है।

जावा 10 के तहत चलने पर, दोनों शाखाओं \META-INF\Versions ; विशेष रूप से, जावा 10 से संस्करण ए, जावा 9 से संस्करण बी, और डिफ़ॉल्ट संस्करण सी और डी।

इसलिए, यदि आपके आवेदन में आपको जावा 9 से नए प्रोसेसब्यूलर एपीआई की आवश्यकता है, लेकिन आपको यह सुनिश्चित करने की आवश्यकता है कि एप्लिकेशन जावा 8 के तहत काम करना जारी रखता है, तो बस अपनी मेट्रा \META-INF\Versions\9 प्रोसेसब्यूरल का उपयोग करते हुए अपनी कक्षाओं के नए संस्करण \META-INF\Versions\9 , और डिफ़ॉल्ट रूप से उपयोग किए जाने वाले संग्रह के मुख्य भाग में पुरानी कक्षाओं को छोड़ दें। पिछड़ी अनुकूलता का त्याग किए बिना जावा 9 की नई विशेषताओं का उपयोग करने का यह सबसे आसान तरीका है।

Java 9 JDK में jar.exe टूल का एक संस्करण है जो बहु-संस्करण JAR फ़ाइलों के निर्माण का समर्थन करता है। अन्य गैर-JDK उपकरण भी यह सहायता प्रदान करते हैं।

जावा 9: मॉड्यूल, मॉड्यूल हर जगह

जावा 9 मॉड्यूल सिस्टम (जिसे प्रोजेक्ट आरा के रूप में भी जाना जाता है) निस्संदेह जावा 9 में सबसे बड़ा बदलाव है। मॉडर्नाइजेशन लक्ष्यों में से एक जावा के एनकैप्सुलेशन तंत्र को मजबूत करना है ताकि डेवलपर निर्दिष्ट कर सके कि कौन से एपीआई अन्य घटकों को प्रदान किए जाते हैं और गणना कर सकते हैं, मॉड्यूल जेवीएम एनकैप्सुलेशन लागू करेगा। वर्ग या वर्ग के सदस्यों के लिए public/protected/private एक्सेस मॉडिफायर की तुलना में इनकैप्सुलेशन मॉडुलन के साथ अधिक शक्तिशाली है।

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

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

सबसे पहले, JAR फ़ाइल के मूल में मॉड्यूल-info.class फ़ाइल (मॉड्यूल-info.java से संकलित) की उपस्थिति के साथ JAR फ़ाइल संशोधित (और मॉड्यूल में बदल जाती है) हो जाती है। module-info.java में मेटाडेटा होता है, विशेष रूप से, उस मॉड्यूल का नाम जिसके पैकेज निर्यात किए जाते हैं (जो कि बाहर से दिखाई देते हैं), इस मॉड्यूल को कौन से मॉड्यूल की आवश्यकता है और कुछ अन्य जानकारी।

module-info.class में जानकारी केवल तब दिखाई देती है जब JVM इसकी तलाश करता है - अर्थात, सिस्टम सामान्य रूप से मॉड्यूलर JAR फ़ाइलों का व्यवहार करता है यदि यह जावा के पुराने संस्करणों के साथ काम करता है (यह माना जाता है कि कोड जावा के पुराने संस्करण के साथ काम करने के लिए संकलित किया गया था। कड़ाई से बोलते हुए, यह थोड़ा रसायन शास्त्र लेता है, और यह अभी भी जावा 9 है जो मॉड्यूल-जानकारी.क्लास के लक्ष्य संस्करण के रूप में निर्दिष्ट है, लेकिन यह वास्तविक है)।

इस प्रकार, आपको जावा 8 और नीचे के साथ मॉड्यूलर जेएआर फाइलें चलाने में सक्षम होना चाहिए, बशर्ते कि अन्य मामलों में वे जावा के पुराने संस्करणों के साथ भी संगत हों। यह भी ध्यान दें कि module-info.class , आरक्षण के साथ, बहु-संस्करण JAR फ़ाइलों के संस्करण क्षेत्रों में रखी जा सकती हैं ।

जावा 9 में, एक क्लासपाथ और एक मॉड्यूल पथ दोनों है। और एक मॉड्यूल पथ। क्लासपाथ हमेशा की तरह काम करता है। यदि आप एक क्लाथपाथ में एक मॉड्यूलर JAR फ़ाइल डालते हैं, तो यह किसी अन्य JAR फ़ाइल की तरह बर्बाद हो जाती है। यही है, यदि आपने JAR फ़ाइल को संशोधित किया है, और आपका एप्लिकेशन अभी तक इसे मॉड्यूल के रूप में मानने के लिए तैयार नहीं है, तो आप इसे क्लासपाथ में रख सकते हैं, यह हमेशा की तरह काम करेगा। आपकी विरासत कोड को इसे काफी सफलतापूर्वक संभालना चाहिए।

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

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

JAR फ़ाइल को क्लासपाथ से मॉड्यूल पथ पर स्थानांतरित करना मुश्किल नहीं है - और मॉडर्लाइज़ेशन का पूरा लाभ उठाएं। सबसे पहले, आप JAR फ़ाइल में module-info.class फ़ाइल जोड़ सकते हैं, और फिर मॉड्यूल पथ में मॉड्यूलर JAR फ़ाइल डाल सकते हैं। इस तरह का एक नया बना मॉड्यूल अभी भी क्लासपैथ JAR की सभी बची हुई JAR फाइलों को एक्सेस करने में सक्षम होगा, क्योंकि वे अनाम मॉड्यूल में प्रवेश करते हैं और एक्सेस में रहते हैं।

यह भी संभव है कि आप JAR फ़ाइल को मॉड्यूलेट नहीं करना चाहते हैं, या यह कि JAR फाइल आपके लिए नहीं, बल्कि किसी और की है, इसलिए आप इसे स्वयं मॉड्यूलेट नहीं कर सकते। इस स्थिति में, JAR फ़ाइल को अभी भी मॉड्यूल पथ में रखा जा सकता है, यह एक स्वचालित मॉड्यूल बन जाएगा।

एक स्वचालित मॉड्यूल को एक मॉड्यूल माना जाता है, भले ही उसमें module-info.class । यह मॉड्यूल JAR फ़ाइल के समान नाम है, और अन्य मॉड्यूल स्पष्ट रूप से इसका अनुरोध कर सकते हैं। यह स्वचालित रूप से अपने सभी सार्वजनिक रूप से उपलब्ध एपीआई और पढ़ता है (यानी, आवश्यकता है) अन्य सभी नामित मॉड्यूल के साथ-साथ नाममात्र मॉड्यूल का निर्यात करता है।

इस प्रकार, एक classpath से एक unmodularized JAR फ़ाइल को बिल्कुल भी कुछ किए बिना एक मॉड्यूल में बदल दिया जा सकता है। अंतर्निहित JAR फाइलें स्वचालित रूप से मॉड्यूल में बदल जाती हैं, उनके पास बस कुछ जानकारी का अभाव होता है जो यह निर्धारित करता है कि क्या सभी आवश्यक मॉड्यूल जगह में हैं, या यह निर्धारित करें कि क्या गायब है।

प्रत्येक अनमॉडर्लाइज्ड JAR फ़ाइल को मॉड्यूल पथ पर नहीं ले जाया जा सकता है और स्वचालित मॉड्यूल में बदल दिया जाता है। एक नियम है: एक पैकेज सिर्फ एक नामित मॉड्यूल का हिस्सा हो सकता है । यही है, अगर एक पैकेज एक से अधिक JAR फ़ाइल में स्थित है, तो संरचना में इस पैकेज के साथ केवल एक JAR फ़ाइल को एक स्वचालित मॉड्यूल में बदल दिया जा सकता है। बाकी क्लासपाथ में रह सकते हैं और अनाम मॉड्यूल में शामिल हो सकते हैं।

पहली नज़र में, यहाँ वर्णित तंत्र जटिल लगता है, लेकिन व्यवहार में यह बहुत सरल है। वास्तव में, इस मामले में यह सिर्फ इतना है कि आप पुरानी JAR फ़ाइलों को क्लासपाथ में छोड़ सकते हैं या उन्हें मॉड्यूल पथ पर ले जा सकते हैं। आप उन्हें मॉड्यूल में तोड़ सकते हैं या नहीं। और जब आपकी पुरानी JAR फाइलें मॉडरेट की जाती हैं, तो आप उन्हें क्लासपाथ में छोड़ सकते हैं या उन्हें मॉड्यूल पथ पर ले जा सकते हैं।

ज्यादातर मामलों में, सब कुछ बस काम करना चाहिए, पहले की तरह। आपकी विरासत में मिली JAR फाइलें नए मॉड्यूलर सिस्टम में रूट करनी चाहिए। जितना अधिक आप कोड को संशोधित करते हैं, उतनी ही निर्भरता की जानकारी जिसे आपको जांचने की आवश्यकता है, और लापता मॉड्यूल और एपीआई को विकास के बहुत पहले चरणों में पता लगाया जाएगा और संभवतः आपको बहुत सारे काम बचाएगा।

जावा 9 "इसे स्वयं करें": मॉड्यूलर JDK और Jlink

विरासत जावा अनुप्रयोगों के साथ एक समस्या यह है कि अंतिम उपयोगकर्ता उपयुक्त जावा वातावरण के साथ काम नहीं कर सकता है। जावा एप्लिकेशन के स्वास्थ्य की गारंटी देने का एक तरीका आवेदन के साथ रनटाइम प्रदान करना है। जावा आपको निजी (पुनर्वितरण योग्य) JRE बनाने की अनुमति देता है जिसे एप्लिकेशन के भीतर वितरित किया जा सकता है। यहाँ निजी JRE बनाने का तरीका बताया गया है। एक नियम के रूप में, JRE फ़ाइल पदानुक्रम लिया जाता है, जो JDK के साथ स्थापित होता है, आवश्यक फ़ाइलें सहेजी जाती हैं, और आपके अनुप्रयोग में आवश्यक कार्यक्षमता वाली वैकल्पिक फ़ाइलों को सहेजा जाता है।

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

तो क्यों नहीं इस काम को जेडीके को सौंप दिया जाए?

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

ऐसी स्व-निहित निष्पादन योग्य छवियां बनाने के लिए एक महत्वपूर्ण संसाधन एक मॉड्यूलर प्रणाली है। अब आप न केवल अपने स्वयं के कोड, बल्कि जावा 9 जेडडीके को भी संशोधित कर सकते हैं। अब जावा क्लास लाइब्रेरी मॉड्यूल का एक संग्रह है, और JDK टूल में मॉड्यूल भी शामिल हैं। मॉड्यूल सिस्टम के लिए आपको बेस क्लास मॉड्यूल को निर्दिष्ट करने की आवश्यकता होती है जो आपके कोड में आवश्यक होते हैं, और आप आवश्यक JDK तत्वों को निर्दिष्ट करते हैं।

इसे सभी को एक साथ लाने के लिए, जावा 9 एक विशेष नया टूल प्रदान करता है जिसे jlink कहा जाता है । जिंकल लॉन्च करने से, आपको फ़ाइलों का एक पदानुक्रम मिलता है - वास्तव में जिन्हें आपको अपना एप्लिकेशन चलाने की आवश्यकता है, कोई और अधिक, कोई कम नहीं। ऐसा सेट मानक JRE की तुलना में बहुत छोटा होगा, इसके अलावा, यह प्लेटफ़ॉर्म-विशिष्ट होगा (अर्थात, एक विशिष्ट ऑपरेटिंग सिस्टम और मशीन के लिए चुना जाएगा)। इसलिए, यदि आप अन्य प्लेटफार्मों के लिए ऐसी निष्पादन योग्य छवियां बनाना चाहते हैं, तो आपको प्रत्येक विशिष्ट प्लेटफॉर्म पर इंस्टॉलेशन के संदर्भ में जिन्न को चलाने की आवश्यकता होगी, जिसके लिए आपको ऐसी छवि की आवश्यकता है।

यह भी नोट करें: यदि आप एक ऐसे एप्लिकेशन के साथ जिंकल चलाते हैं जिसमें कुछ भी संशोधित नहीं है, तो टूल में JRE को निचोड़ने के लिए आवश्यक जानकारी नहीं है, इसलिए jlink के पास पूरे JRE को पैक करने के अलावा कुछ नहीं होगा। इस मामले में भी, यह आपके लिए थोड़ा अधिक सुविधाजनक होगा: जिंक आपके लिए JRE पैक करेगा, इसलिए आप इस बारे में चिंता नहीं कर सकते कि फ़ाइल पदानुक्रम को सही तरीके से कैसे कॉपी करें।

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

पुराने और नए का मिलन

, Java- , , . Java 9, , API , ( ) , , Java.

Java 9: -, , , Java.

JAR- Java 9 JAR-, Java . , Java 9, Java 8 – .

Java, , JAR- , . , , « » .

JDK jlink, , . , Java – .

Java, Java 9 , – , , Java.