एंड्रॉइड एप्लिकेशन में जावा से कोटलिन माइग्रेशन को बुरी तरह से विफल कैसे करें

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

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

इस लेख में मैं आपको बताऊंगा कि क्या होगा यदि मैंने ठेस पर तुरंत इस रणनीति का पालन करने का फैसला किया, और अपने छोटे प्रोजेक्ट पर इसे नहीं आजमाया।

मेरे छोटे से प्रोजेक्ट को पूरा करो

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

कोटलिन + लोम्बोक = :(

अपने आवेदन में, मैंने गेटर्स और सेटरर्स उत्पन्न करने के लिए लोम्बोक लाइब्रेरी का उपयोग किया। लोमबोक जेवैक का एक एनोटेशन प्रोसेसर है। दुर्भाग्य से, कोटलिन संकलक प्रसंस्करण एनोटेशन [स्रोत] के बिना javac का उपयोग करता है। इसका मतलब यह है कि लोम्बॉक के साथ बनाए गए तरीके कोटलिन में उपलब्ध नहीं होंगे:

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

मैंने उसी तरह सोचा। लेकिन मुझे एक वास्तविक समस्या का सामना करना पड़ा जब मैं एप्लिकेशन में एक नई स्क्रीन जोड़ना चाहता था।

कोटलिन + लोम्बोक + डैगर 2 =: (((

मेरे आवेदन निर्भरता को इंजेक्ट करने के लिए डैगर 2 का उपयोग करता है। एक नई स्क्रीन बनाते समय, मैं आमतौर पर एक एमवीपी संरचना बनाता हूं: गतिविधि, प्रस्तुतकर्ता, घटक, मॉड्यूल और अनुबंध। प्रस्तुतकर्ता के लिए सभी निर्भरता डैगर का उपयोग करके कार्यान्वित की जाती है। गतिविधि कॉल DaggerSomeComponent.builder().(...).build().inject(this) आवश्यक निर्भरता के साथ प्रस्तुतकर्ता को इंजेक्ट करने के लिए।

Kotlin के साथ Dagger 2 का उपयोग करना कोई समस्या नहीं है। इससे पहले, आपको kapt प्लगइन लागू करने की आवश्यकता है, जो डैगर के लिए आवश्यक स्व-उत्पन्न कक्षाएं बनाता है।

और यहाँ यह सब अलग होने लगता है

Kapt plugin के बिना, मैं Kotlin फ़ाइलों में उत्पन्न डैगर वर्गों का उपयोग नहीं कर सकता था। लेकिन मैंने इस प्लगइन को जोड़ने के बाद, लोम्बोक द्वारा बनाए गए सभी तरीके गायब हो गए!

Kapt प्लगइन लगाने से पहले:

Kapt प्लगइन लगाने के बाद:

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

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

यह वह है जो इस भयानक बहुभुज MVP संरचना को बिना kapt प्लगइन के जैसा लगेगा:

लेकिन मैं अभी भी कोटलिन में जाना चाहता हूं। मैं क्या करूँ?

एक तरीका विभिन्न मॉड्यूल का उपयोग करना है । कोटलिन उन तरीकों को नहीं देखेगा, जो लोम्बोक स्रोत कोड में उत्पन्न करेगा, लेकिन उन्हें बायटेकोड में देखेंगे।

व्यक्तिगत रूप से, यह मुझे लगता है कि यह सबसे पसंदीदा तरीका है। यदि आप प्रत्येक सुविधा के लिए कोटलिन को अलग-अलग निर्भर मॉड्यूल में रखते हैं, तो आप ऐसी संगतता समस्याओं के जोखिम को कम करते हैं जो मुझे सामना करना पड़ा, या आधिकारिक गाइड में सूचीबद्ध अधिक जटिल हैं।

और यह सब नहीं है। स्पष्ट पृथक्करण के बिना कोटलिन और जावा फ़ाइलों को मिलाने के कई अन्य नुकसान हैं। यह परियोजना पर आपके साथ काम करने वाले सभी डेवलपर्स को दोनों भाषाओं को जानता है। यह कोड की पठनीयता को भी कम करता है और निर्माण समय [स्रोत] में वृद्धि का कारण बन सकता है।

संक्षिप्त

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