बिना दर्द के जावा प्लग-इन

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

• हमें विशेष पुस्तकालयों या चौखटे ( OSGi , Guice, आदि) की आवश्यकता नहीं है
• हम ASM और इसी तरह के पुस्तकालयों के साथ बाइटकोड पार्सिंग का उपयोग नहीं करेंगे।
• हम अपना क्लास लोडर नहीं लिखेंगे।
• हम प्रतिबिंब और एनोटेशन का उपयोग नहीं करेंगे।
• प्लगइन्स खोजने के लिए क्लासपाथ के साथ उपद्रव करने की आवश्यकता नहीं है। हम क्लासपाथ को बिल्कुल नहीं छूएंगे।
• साथ ही, हम विस्तार बिंदुओं (प्लगइन्स में विस्तार बिंदु) का वर्णन करने के लिए XML, YAML या किसी अन्य घोषणात्मक भाषाओं का उपयोग नहीं करेंगे।

हालांकि, अभी भी एक आवश्यकता है - ऐसा समाधान केवल जावा 9 या उच्चतर पर काम करेगा। क्योंकि यह मॉड्यूल और सेवाओं पर आधारित होगा।

तो चलिए शुरू करते हैं। हम समस्या को अधिक विशेष रूप से तैयार करते हैं:

आपको एक न्यूनतम एप्लिकेशन फ्रेमवर्क लागू करने की आवश्यकता है, जो स्टार्टअप पर plugins फ़ोल्डर से उपयोगकर्ता प्लगइन्स को लोड करेगा।

यही है, इकट्ठे आवेदन कुछ इस तरह दिखना चाहिए:

 plugin-app/ plugins/ plugin1.jar plugin2.jar ... core.jar … 

core मॉड्यूल के साथ शुरू करते हैं। यह मॉड्यूल हमारे अनुप्रयोग का मूल है, जो वास्तव में, हमारा ढांचा है।


मॉड्यूल में निम्नलिखित 4 जावा फाइलें बनाएं:

 core/ src/main/java/ org/example/pluginapp/core/ IService.java BasicService.java Main.java module-info.java 

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

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

IService.java फ़ाइल निम्नानुसार है:

 … public interface IService { void doJob(); static List<IService> getServices(ModuleLayer layer) { return ServiceLoader .load(layer, IService.class) .stream() .map(Provider::get) .collect(Collectors.toList()); } } 

इस प्रकार, IService सिर्फ एक इंटरफ़ेस है जो कुछ सार doJob() (मैं दोहराता हूं, विवरण महत्वपूर्ण नहीं हैं, वास्तव में यह कुछ ठोस होगा)।

दूसरे getServices() पद्धति पर भी ध्यान दें। यह विधि IService इंटरफ़ेस के सभी कार्यान्वयनों को वापस करती है जो इसे इस मॉड्यूल परत और इसके माता-पिता में मिली थी। हम इस बारे में अधिक विस्तार से बाद में बात करेंगे।

दूसरी फ़ाइल, BasicService.java , IService इंटरफ़ेस का आधार कार्यान्वयन है। यह हमेशा मौजूद रहेगा, भले ही एप्लिकेशन में कोई प्लगइन्स न हों। दूसरे शब्दों में, core न केवल कोर है, बल्कि एक ही समय में खुद के लिए एक प्लगइन भी है, जो हमेशा लोड होगा। BasicService.java फ़ाइल इस तरह दिखाई देती है:

 … public class BasicService implements IService { @Override public void doJob() { System.out.println("Basic service"); } } 

सरलता के लिए, doJob() केवल "Basic service" स्ट्रिंग को प्रिंट करता है और यह है।

इस प्रकार, इस समय हमारे पास निम्न चित्र है:



तीसरी फ़ाइल, Main.java , वह है जहाँ main() पद्धति लागू की गई है। इसमें थोड़ा जादू है, जिसे समझने के लिए आपको यह जानना होगा कि मॉड्यूल परत क्या है।

मॉड्यूल परतों के बारे में

जब जावा एप्लिकेशन को लॉन्च करता है, तो सभी प्लेटफ़ॉर्म मॉड्यूल + मॉड्यूल --module-path में सूचीबद्ध होते हैं --module-path (और भी classpath , यदि कोई हो) तथाकथित Boot लेयर में आते हैं। हमारे मामले में, यदि हम core.jar मॉड्यूल को संकलित करते हैं और कमांड लाइन से java --module-path core.jar --module core , तो Boot परत में कम से कम java.base और core मॉड्यूल होंगे:



Boot परत हमेशा किसी भी जावा अनुप्रयोग में मौजूद होती है, और यह सबसे छोटा संभव विन्यास है। अधिकांश अनुप्रयोग मॉड्यूल की एक एकल परत में मौजूद होते हैं। हालाँकि, हमारे मामले में, हम plugins फ़ोल्डर से प्लगइन्स का डायनेमिक लोडिंग करना चाहते हैं। हम उपयोगकर्ता को एप्लिकेशन लॉन्च लाइन को सही करने के लिए मजबूर कर सकते हैं ताकि वह स्वयं आवश्यक प्लग --module-path इन --module-path को --module-path , लेकिन यह सबसे अच्छा समाधान नहीं होगा। विशेष रूप से वे लोग जो प्रोग्रामर नहीं हैं और समझ में नहीं आता कि उन्हें इतनी सरल चीज़ के लिए कहीं और चढ़ने और कुछ ठीक करने की आवश्यकता क्यों है।

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



तथ्य यह है कि प्लगइन परत में Boot परत है जैसा कि माता-पिता का मतलब है कि प्लगइन परत से मॉड्यूल Boot परत से मॉड्यूल को संदर्भित कर सकते हैं, लेकिन इसके विपरीत नहीं।

इसलिए, अब यह जानना कि एक मॉड्यूल लेयर क्या है, आप अंततः Main.java फ़ाइल की सामग्री को देख सकते हैं:

 … public final class Main { public static void main(String[] args) { Path pluginsDir = Paths.get("plugins"); //      plugins ModuleFinder pluginsFinder = ModuleFinder.of(pluginsDir); //  ModuleFinder      plugins       List<String> plugins = pluginsFinder .findAll() .stream() .map(ModuleReference::descriptor) .map(ModuleDescriptor::name) .collect(Collectors.toList()); //  ,      (   ) Configuration pluginsConfiguration = ModuleLayer .boot() .configuration() .resolve(pluginsFinder, ModuleFinder.of(), plugins); //      ModuleLayer layer = ModuleLayer .boot() .defineModulesWithOneLoader(pluginsConfiguration, ClassLoader.getSystemClassLoader()); //     IService       Boot List<IService> services = IService.getServices(layer); for (IService service : services) { service.doJob(); } } } 

यदि आप पहली बार इस कोड को देख रहे हैं, तो यह बहुत जटिल लग सकता है, लेकिन बड़ी संख्या में नए अज्ञात वर्गों के कारण यह एक गलत सनसनी है। यदि आप ModuleFinder , कॉन्फ़िगरेशन और ModuleLayer कक्षाओं के अर्थ के बारे में थोड़ा समझते हैं , तो सब कुछ ठीक हो जाता है। और इसके अलावा, केवल कुछ दर्जन लाइनें हैं! यह सभी तर्क हैं जो एक बार लिखे गए हैं।

मॉड्यूल विवरणक

एक और (चौथी) फ़ाइल है जिसे हमने नहीं माना: module-info.java । यह सबसे छोटी फ़ाइल है जिसमें हमारे मॉड्यूल की घोषणा और सेवाओं का विवरण (विस्तार बिंदु) शामिल हैं:

 … module core { exports org.example.pluginapp.core; uses IService; provides IService with BasicService; } 

इस फ़ाइल की पंक्तियों का अर्थ स्पष्ट होना चाहिए:

• सबसे पहले, मॉड्यूल org.example.pluginapp.core पैकेज निर्यात करता है, org.example.pluginapp.core प्लग इन IService इंटरफ़ेस से प्राप्त हो सके (अन्यथा IService core मॉड्यूल के बाहर सुलभ नहीं होगा)।
• दूसरे, वह घोषणा करता है कि वह IService का उपयोग कर रहा है।
• तीसरा, वह कहता है कि वह BasicService वर्ग के माध्यम से IService सेवा का कार्यान्वयन प्रदान करता है।

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

तो, फ्रेम तैयार है। आइए इसे चलाने का प्रयास करें:

 > java --module-path core.jar --module core Basic service 

क्या हुआ?

1. जावा ने plugins फ़ोल्डर में मॉड्यूल खोजने की कोशिश की और कोई भी नहीं मिला।
2. एक खाली परत बनाई गई थी।
3. ServiceLoader ने सभी IService कार्यान्वयन के लिए खोज शुरू की।
4. खाली परत में, उन्हें कोई सेवा कार्यान्वयन नहीं मिला, क्योंकि वहां कोई मॉड्यूल नहीं हैं।
5. इस परत के बाद, उन्होंने मूल परत (यानी, Boot परत) में खोज जारी रखी और core मॉड्यूल में BasicService का एक कार्यान्वयन पाया।
6. सभी पाया कार्यान्वयनों में doJob() पद्धति थी। चूंकि केवल एक कार्यान्वयन पाया गया था, केवल "Basic service" मुद्रित की गई थी।

एक प्लगइन लेखन

हमारे एप्लिकेशन का मुख्य भाग लिखने के बाद, अब इसके लिए प्लगइन्स लिखने की कोशिश करने का समय है। चलो दो प्लगइन्स plugin1 और plugin2 : पहला प्रिंट "Service 1" , दूसरा - "Service 2" । ऐसा करने के लिए, आपको क्रमशः plugin1 और plugin2 में plugin1 और plugin2 कार्यान्वयन प्रदान करने की आवश्यकता है:



दो फ़ाइलों के साथ पहला प्लगइन बनाएँ:

 plugin1/ src/main/java/ org/example/pluginapp/plugin1/ Service1.java module-info.java 

Service1.java फ़ाइल:

 … public class Service1 implements IService { @Override public void doJob() { System.out.println("Service 1"); } } 

module-info.java फ़ाइल:

 … module plugin1 { requires core; provides IService with Service1; } 

ध्यान दें कि plugin1 core निर्भर है। यह निर्भरता व्युत्क्रम सिद्धांत है जिसका मैंने पहले उल्लेख किया है: कर्नेल प्लगइन्स पर निर्भर नहीं करता है, लेकिन इसके विपरीत।

दूसरा प्लगइन पूरी तरह से पहले जैसा है, इसलिए मैं इसे यहां नहीं दूंगा।

अब हम प्लगइन्स इकट्ठा करते हैं, उन्हें plugins फ़ोल्डर में डालते हैं और एप्लिकेशन चलाते हैं:

 > java --module-path core.jar --module core Service 1 Service 2 Basic service 

हुर्रे, प्लगइन्स उठाए गए थे! यह कैसे हुआ:

1. जावा को plugins फ़ोल्डर में दो मॉड्यूल मिले।
2. दो मॉड्यूल plugins1 और plugins2 के साथ एक परत बनाई गई थी।
3. ServiceLoader ने सभी IService कार्यान्वयन के लिए खोज शुरू की।
4. प्लगइन परत में, उन्होंने IService सेवा के दो कार्यान्वयन पाए।
5. उसके बाद, उन्होंने मूल परत (यानी, Boot परत) में खोज जारी रखी और core मॉड्यूल में BasicService का एक कार्यान्वयन पाया।
6. सभी पाया कार्यान्वयनों में doJob() पद्धति थी।

ध्यान दें कि ठीक है क्योंकि सेवा प्रदाताओं की खोज बच्चे की परतों से शुरू होती है, और फिर माता-पिता की परतों तक जाती है, फिर "Service 1" और "Service 2" पहले मुद्रित होती "Service 2" , और फिर "Basic Service" । यदि आप चाहते हैं कि सेवाओं को क्रमबद्ध किया जाए ताकि बुनियादी सेवाएं पहले जाएं, और फिर प्लगइन्स, तो आप वहां छँटाई जोड़कर IService.getServices() विधि को int getOrdering() सकते हैं (आपको int getOrdering() इंटरफ़ेस में int getOrdering() विधि जोड़ने की आवश्यकता हो सकती है)।

परिणाम

तो, मैंने दिखाया कि आप कैसे जल्दी और कुशलता से प्लग-इन जावा एप्लिकेशन को व्यवस्थित कर सकते हैं जिसमें निम्नलिखित गुण हैं:

• सादगी: विस्तार बिंदुओं और उनके बाइंडिंग के लिए, केवल मूल जावा सुविधाएँ (इंटरफेस, कक्षाएं, और ServiceLoader ) का उपयोग किया जाता है, फ्रेमवर्क, प्रतिबिंब, एनोटेशन और क्लास लोडर के बिना।
• घोषणा: विस्तार विवरण मॉड्यूल विवरणकों में वर्णित हैं। बस module-info.java को module-info.java और समझें कि क्या विस्तार बिंदु मौजूद हैं और इन बिंदुओं पर कौन से प्लगइन्स योगदान करते हैं।
• स्टेटिक गारंटी: मॉड्यूल डिस्क्रिप्टर में त्रुटियों के मामले में, कार्यक्रम संकलित नहीं करेगा। इसके अलावा, एक बोनस के रूप में, यदि आप IntelliJ IDEA का उपयोग करते हैं, तो आपको अतिरिक्त चेतावनी मिलेगी (उदाहरण के लिए, यदि आप उपयोग करना भूल जाते हैं और ServiceLoader.load() उपयोग करते हैं)
• सुरक्षा: मॉड्यूलर जावा सिस्टम स्टार्टअप पर जांच करता है कि मॉड्यूल का कॉन्फ़िगरेशन सही है और त्रुटियों के मामले में प्रोग्राम को निष्पादित करने से इनकार करता है।

मैं दोहराता हूं, मैंने केवल विचार दिखाया है। एक वास्तविक प्लग-इन एप्लिकेशन में, दसियों से सैकड़ों मॉड्यूल और सैकड़ों से हजारों एक्सटेंशन पॉइंट होंगे।

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

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

मेरे बारे में संक्षेप में

मैं 10 से अधिक वर्षों (जावा में उनमें से 8) के लिए प्रोग्रामिंग कर रहा हूं, मैं स्टैकऑवरफ्लो का जवाब देता हूं और टेलीग्राम में अपना चैनल जावा को समर्पित करता हूं।