क्या एक बड़े जार में सभी जार निर्भरताओं को पैकेज करना संभव है?

Question

मुझे पता है कि यह "सर्वोत्तम अभ्यास" नहीं है, लेकिन क्या मैं एक बड़ी जार में सभी निर्भरताओं को शामिल कर सकता हूं?

Answer 1

One-Jar नामक एक उपयोगिता है जो आप चाहते हैं, हालांकि मैं इसके खिलाफ सलाह दूंगा। प्रदर्शन आमतौर पर भयानक है।

Answer 2

अक्सर आप कर सकते हैं, लेकिन कभी कभी वहाँ असामान्य कानूनी या तकनीकी कारणों नहीं कर रहे हैं।

• कानूनी: उदाहरण के लिए, हम उस समय हम, हम अपने एप्लिकेशन के बाकी के साथ एक बड़ा पैकेज में एक साथ JavaMail जार फ़ाइलों बंडल नहीं कर सकता है चाहता था की खोज की है, लेकिन लाइसेंस समझौते हमने कहा उन्हें अलग रखना था।

• तकनीकी: एक और समस्या कस्टम क्लास लोडर विशिष्ट जार फ़ाइलों के अंदर विशिष्ट संसाधनों या कक्षाओं के लिए देख सकते हैं। यह प्रायः अनुप्रयोग सर्वर या ईएसबी के लिए कंटेनरों के संदर्भ में होता है।

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

Answer 3

यदि आप ऐसा करना चाहते हैं तो Jar Jar Links नामक एक उपकरण है जो आपके लिए यह करेगा। इसका इस्तेमाल कभी नहीं किया लेकिन नाम भूलना मुश्किल है।

Answer 4

मैं jar-with-dependencies वर्णनकर्ता साथ maven assembly plugin इस्तेमाल किया

Answer 5

• आप फ़ाइलों unjar और कमांड लाइन का उपयोग कर उन्हें repack कर सकते हैं

• के लिए आप [uberjar]

• आप उपयोग कर सकते हैं fatjar

Answer 6

का उपयोग अच्छे पुराने चींटी: सिर्फ चींटी Zip task

<zip destfile="out.jar"> 
    <zipgroupfileset dir="lib" includes="*.jar"/> 
</zip> 

इस के साथ zipgroupfileset का उपयोग सभी शामिल जार पुस्तकालयों 'सामग्री समतल होगा।

Answer 7

ग्रहण 3.4 और ऊपर आपको यह करने की अनुमति देता है। अपनी प्रोजेक्ट पर राइट क्लिक करें, निकालें का चयन करें, और रननेबल जार विकल्प पर नेविगेट करें। अगला का चयन करें। उपयुक्त सेटिंग्स और अपना बंद और चलाना चुनें। मुझे यह भी याद है कि यह कार्यक्षमता उसी या समान पुस्तकालयों का उपयोग करके हासिल की जाती है जो फतजार (ऊपर वर्णित) का उपयोग करता है।

Answer 8

बस पूर्णता के लिए, ProGuard आपके लिए यह भी करेगा, साथ ही साथ वैकल्पिक रूप से अपर्याप्त और जार को कम करना होगा। उत्तरार्द्ध समारोह विशेष रूप से अंतिम तैनाती JAR बनाने के लिए उपयोगी है।

Answer 9

यह भी याद रखें कि .jar फ़ाइलें हैं।कवर के तहत ज़िप फ़ाइलें। आप अपने पसंदीदा ज़िप उपकरण का उपयोग कर उन्हें फिर से पैकेज कर सकते हैं। इस मामले में, आपको स्वयं प्रकट फ़ाइल से निपटना होगा।

Answer 10

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

नीचे मेरे आवेदन में वन-जार द्वारा पेश किए गए प्रदर्शन प्रभाव को मापने का प्रयास नीचे दिया गया है। यह स्विंग-आधारित जीयूआई एप्लीकेशन है, जिसमें 352 कक्षाएं प्रोगार्ड 4.5b2 के साथ obfuscated शामिल हैं। वन-जार 0.96 का उपयोग 12 एमबी के पुस्तकालयों (ओडीएफडीओएम, सैक्सन हे, जेरिस, जैक्सन, वीएलडीओकिंग, अपाचे कॉमन्स इत्यादि) के साथ परिणामी कक्षाओं को बंडल करने के लिए किया जाता है। मैंने एक-जार द्वारा संसाधित उसी जार के साथ obfuscated जार के प्रदर्शन की तुलना की है।

• JVM से main() प्रणाली के शुरू होने से शुरू: 0.5s के बिना एक-जार और एक-जार के साथ 1.7s। जेवीएम से स्क्रीन पर एप्लिकेशन विंडो की उपस्थिति से शुरू होता है: एक-जार के बिना 2.3 और वन-जार के साथ 3.4s। तो वन-जार स्टार्टअप समय में 1.1 एस जोड़ता है।
• वन-जार स्क्रीन पर दिखाई देने वाली जेवीएम स्टार्ट और स्प्लैश छवि के बीच देरी में वृद्धि नहीं करेगा (यदि जार मेनिफेस्ट के माध्यम से लागू किया गया है), तो स्टार्टअप समय वृद्धि इंटरैक्टिव एप्लिकेशन के लिए बहुत परेशान नहीं है।
• हम एक वर्ग लोडर के बारे में बात कर रहे हैं, इसलिए कोड निष्पादन गति पर कोई प्रभाव नहीं होना चाहिए, जब तक आप गतिशील वर्ग लोडिंग का उपयोग नहीं कर रहे हों।
• जेवीएम आंकड़े (jconsole के माध्यम से) को देखते हुए पता चलता है कि वन-जार्रेड संस्करण अधिक ढेर स्मृति लेता है। मेरे आवेदन के लिए ओवरहेड एमबी के दसियों के क्रम में है। मैंने 16 एमबी बनाम 40 एमबी, 306 एमबी बनाम 346 एमबी, 131 एमबी बनाम 138 एमबी जैसे आंकड़े देखा, अब आवेदन के बहुत से उपयोगकर्ता डेटा के आधार पर आवेदन किया जा रहा है और अब बहुत समय पहले कचरा कलेक्टर निष्पादित किया गया है।

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

उम्मीद है कि यह मदद करता है।

Answer 11

वन-जेएआर सभी निर्भरता जार स्टार्टअप पर स्मृति में लोड करता है। यह बहुत अक्षम हो सकता है, लेकिन 2004 में इसे रिलीज़ होने के बाद से किसी ने मुझे इसके बारे में शिकायत नहीं की है। प्री-लोडिंग का संभावित प्रभाव एप्लिकेशन के लिए क्लासलोडिंग की एक समग्र गति है, क्योंकि क्लासलोडर को क्लासपाथ को बार-बार स्कैन करना नहीं पड़ता है एप्लिकेशन के रूप में संसाधनों और कक्षाओं के लिए: सब कुछ हैशैप किया गया है।

आलसी लोडर बनाने के लिए यह बहुत आसान है जो ऑन-डिमांड लोड करेगा: लेकिन मैं स्कूल का हूं जो कहता है "बिल्ड-इट, मापन-इट, इट-इट-इट यदि आवश्यक हो" और अब तक कोई नहीं रहा है इसे सुधारने की जरूरत है।

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