क्या जावा 9 + / जावा 11 की ओर पलायन करते समय मॉड्यूल पर स्विच करने की कोई आवश्यकता है?

Question

वर्तमान में हम जावा 8 से जावा 11 की ओर पलायन कर रहे हैं। हालांकि, हमारी सेवाओं का उन्नयन कम दर्दनाक था, जैसा कि हमने अनुमान लगाया था। हमें मूल रूप से केवल अपनी build.gradleफ़ाइल में संस्करण संख्या को बदलना था और सेवाएं खुशी से ऊपर और चल रही थीं। हमने पुस्तकालयों के साथ-साथ (माइक्रो) सेवाओं को अपग्रेड किया है जो उन कामों का उपयोग करते हैं। अब तक कोई समस्या नहीं।

क्या वास्तव में मॉड्यूल पर स्विच करने की कोई आवश्यकता है? यह अनावश्यक लागतों को उत्पन्न करेगा। किसी भी सुझाव या आगे पढ़ने की सामग्री की सराहना की है।

यदि मॉड्यूल पेश किए बिना जावा 9+ कोड का उपयोग किया जाता है, तो स्पष्ट करने के लिए क्या कोई परिणाम हैं? क्या यह अन्य कोड के साथ असंगत हो सकता है?

Comments

यह वही जोखिम है जो आपने पहले ही जावा 8 में सामना किया था: "क्लासपाथ हेल" में समाप्त हुआ था।

Sotms / # सारांश एक हद तक जवाब देने हैं। आप जाँच सकते हैं, यदि आपके प्रोजेक्ट लक्ष्य प्रोजेक्ट आरा से संरेखित हैं । इसके अलावा, मेरी राय में, इसकी तारीख के साथ-साथ अपने उपभोक्ताओं को सहायता प्रदान करने वाली पुस्तकालयों / सेवाओं के लिए भी महत्वपूर्ण है।

— नमन

@ तस्ची मुझे नहीं लगता कि क्लासपैथ नरक अकेले मॉड्यूलर होने को सही ठहराता है, क्योंकि जावा 9 से पहले के सभी कोड में यह मुद्दा था और ज्यादातर मामले में हम इसके साथ ठीक थे (व्यक्तिगत रूप से इसके साथ कभी कोई समस्या नहीं थी)।

— यूनुस ईओ

@ जनमानस परियोजना के लक्ष्यों को प्राप्त कर रहा है। वास्तव में यह एक बहुत अच्छा तर्क है।

— यूनुस ईओ

@ यूयन्स एल ऑयार्ती, "क्लासपाथ हेल" को हटाकर प्रोजेक्ट आरा के दो घोषित लक्ष्यों में से एक है। यदि आपको लगता है कि यह आरा से निपटने के लिए पर्याप्त कारण नहीं है, तो ठीक है ... मैं आपसे सहमत हूं, और जब भी मैं कर सकता हूं, मैं आरा से बचता हूं।

Answer 1

नहीं।

मॉड्यूल पर स्विच करने की कोई आवश्यकता नहीं है।

मॉड्यूल पर स्विच करने की आवश्यकता कभी नहीं हुई है।

जावा 9 और बाद में अनाम मॉड्यूल की अवधारणा के माध्यम से पारंपरिक क्लास पथ पर पारंपरिक JAR फ़ाइलों का समर्थन करता है, और संभवतः ब्रह्मांड की गर्मी से मृत्यु तक ऐसा करेगा।

मॉड्यूल का उपयोग शुरू करने के लिए पूरी तरह से आप पर निर्भर है।

यदि आप एक बड़ी विरासत परियोजना को बनाए रखते हैं जो बहुत अधिक नहीं बदल रही है, तो यह संभवतः प्रयास के लायक नहीं है।

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

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

यदि आप एक पुस्तकालय बनाए रखते हैं तो मैं दृढ़ता से अनुशंसा करता हूं कि यदि आपने ऐसा पहले से नहीं किया है, तो आप इसे एक मॉड्यूल के रूप में अपग्रेड करते हैं, और यदि आपके पुस्तकालय की सभी निर्भरताएँ परिवर्तित हो गई हैं।

यह सब कहने की ज़रूरत नहीं है कि आप जावा 8 को स्थानांतरित करते समय कुछ लड़खड़ाते हुए ब्लॉक का सामना नहीं करेंगे। वे जो आप मुठभेड़ करते हैं, हालांकि, संभवतः प्रति मॉड्यूल के साथ कुछ नहीं करना है । सबसे आम प्रवास समस्याओं है कि हम के बारे में के बाद से हम 2017 में जावा 9 जारी किया सुना है साथ क्या करना है संस्करण स्ट्रिंग के वाक्य रचना में परिवर्तन और को हटाने या आंतरिक एपीआई की कैप्सूलीकरण ( जैसे , sun.misc.Base64Decoder), जो जनता के लिए, समर्थित प्रतिस्थापन है वर्षों से उपलब्ध है।

Answer 2

मैं आपको केवल मामले पर अपने संगठन की राय बता सकता हूं। हम कर रहे हैं मॉड्यूल में जाने, हर एक परियोजना है कि हम पर काम कर रहे के लिए करने की प्रक्रिया में। हम जो निर्माण कर रहे हैं, वह मूल रूप से सूक्ष्म सेवाएँ + कुछ क्लाइंट लाइब्रेरी हैं। माइक्रो-सेवाओं के लिए संक्रमण modulesकिसी भी तरह से कम प्राथमिकता है: कोड वहां पहले से ही किसी तरह डॉकटर कंटेनर में अलग-थलग है, इसलिए वहां "मॉड्यूल" जोड़ना "हमें (महत्वपूर्ण) प्रतीत नहीं होता है। यह काम धीरे-धीरे उठाया जा रहा है, लेकिन यह कम प्राथमिकता है।

दूसरी ओर, क्लाइंट लाइब्रेरी एक पूरी तरह से अलग कहानी है। मैं आपको कभी-कभी होने वाली गंदगी नहीं बता सकता। मैं एक बात समझाता हूँ कि मुझे पहले से नफरत थी jigsaw। आप सभी के उपयोग के लिए, ग्राहकों के लिए एक इंटरफ़ेस उजागर करते हैं। स्वचालित रूप से वह interfaceहै public- दुनिया के सामने। आमतौर पर, मैं क्या करता हूं, तब कुछ package-privateकक्षाएं होती हैं, जो ग्राहकों के सामने नहीं आती हैं, जो उस इंटरफ़ेस का उपयोग करती हैं। मैं नहीं चाहता कि ग्राहक इसका उपयोग करें, यह आंतरिक है। बढ़िया है? गलत।

पहली समस्या यह है कि जब वे package-privateकक्षाएं बढ़ती हैं, और आप अधिक कक्षाएं चाहते हैं, तो सब कुछ छिपाए रखने का एकमात्र तरीका है कि उसी वर्ग में कक्षाएं बनाई जाएं :

  package abc:
        -- /* non-public */ Usage.java
        -- /* non-public */ HelperUsage.java
        -- /* non-public */ FactoryUsage.java
        ....

जब यह बढ़ता है (हमारे मामलों में ऐसा होता है), तो वे पैकेज बहुत बड़े हैं। एक अलग पैकेज पर चलते हुए आप कहते हैं? ज़रूर, लेकिन फिर वह HelperUsageऔर FactoryUsageहोगा publicऔर हमने शुरू से ही इससे बचने की कोशिश की।

समस्या नंबर दो: हमारे ग्राहकों का कोई भी उपयोगकर्ता / कॉलर एक ही पैकेज का नाम बना सकता है और उन छिपी हुई कक्षाओं का विस्तार कर सकता है। यह हमारे लिए कुछ समय पहले ही हुआ, मजेदार समय।

modulesहल करती है एक सुंदर तरीके से इस समस्या: publicनहीं है वास्तव में public अब और; मैं निर्देशन के friendमाध्यम से पहुँच सकता हूँ exports to। इससे हमारा कोड जीवनचक्र और प्रबंधन बहुत आसान हो जाता है। और हम क्लासपाथ नरक से दूर हो जाते हैं। बेशक maven/gradleसंभाल कि हमारे लिए, मुख्य रूप से, लेकिन जब वहाँ एक समस्या है, दर्द बहुत ही वास्तविक हो जाएगा। कई अन्य उदाहरण भी हो सकते हैं।

उस ने कहा, संक्रमण (अभी भी) आसान नहीं है। सबसे पहले, टीम पर सभी को गठबंधन करने की आवश्यकता है; दूसरी बाधाएँ हैं। सबसे बड़ा दो जो मैं अभी भी देख रहा हूं: विशेष रूप से किसके आधार पर, आप प्रत्येक मॉड्यूल को अलग करते हैं? मेरे पास एक निश्चित उत्तर नहीं है, फिर भी। दूसरा है split-packages, ओह सुंदर "एक ही वर्ग विभिन्न मॉड्यूल द्वारा निर्यात किया जाता है"। यदि आपके पुस्तकालयों के साथ ऐसा होता है, तो कम करने के तरीके हैं; लेकिन अगर ये बाहरी पुस्तकालय हैं ... इतना आसान नहीं है ।

यदि आप ( jarAऔर jarBअलग मॉड्यूल) पर निर्भर हैं , लेकिन वे दोनों निर्यात abc.def.Utilकरते हैं, तो आप आश्चर्यचकित हैं। हालांकि इसे हल करने के तरीके हैं। किसी तरह दर्दनाक, लेकिन सॉल्व।

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

Comments

भड़काने के लिए धन्यवाद! तो मुझे जो मिल रहा है, वह यह है कि मॉडर्नाइजेशन बहुत जरूरी पहुंच प्रतिबंधों के साथ आता है जो हम पिछले संस्करणों में याद कर रहे हैं। मैं निश्चित रूप से देख सकता हूं कि यह पुस्तकालयों के लिए कैसे उपयोगी है। यदि किसी सेवा में REST / AMQP / etc के माध्यम से संचार किया जाता है। यह फिर से एक मुद्दे का इतना नहीं है, या बल्कि, कोई लाभ नहीं हैं? शायद हम मनमाने ढंग से यह नहीं कह सकते कि सभी जावा 9+ कोड मॉड्यूलर होना चाहिए? तो हमें इसे "उपकरण" के रूप में मानना ​​चाहिए? फिर भी दिलचस्प है।

— ईओ

आप जो उपयोगी पा सकते हैं वह एक "एक्सेसर" एपीआई पैटर्न है (लेकिन कृपया ध्यान दें कि सार्वजनिक स्थैतिक क्षेत्र के बजाय, तरीकों के साथ एक निजी पसंद किया जाता है, वर्ग लोडिंग के दौरान गतिरोध से बचने के लिए)। यहां देखें: wiki.netbeans.org/…

— Tomáš Myšík

अपना अनुभव बांटने के लिये धन्यवाद! यह अच्छा होगा यदि आप उन समस्याओं के बारे में अधिक विवरण या लिंक साझा करेंगे जो आपको दर्दनाक हैं, लेकिन फिर भी हल करने योग्य हैं।

— बॉटिस्मेरियस

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

— VGR