जावा फ्रेंडली कोटलिन कोड लिखना

बाहर से, ऐसा लग सकता है कि कोटलिन ने नई कठिनाइयों को पेश किए बिना एंड्रॉइड विकास को सरल बना दिया है: भाषा जावा-संगत है, इसलिए यहां तक ​​कि एक बड़े जावा प्रोजेक्ट को धीरे-धीरे बिना किसी को परेशान किए, इसमें अनुवाद किया जा सकता है? लेकिन अगर आप गहराई से देखते हैं, तो प्रत्येक बॉक्स में एक डबल तल होता है, और ड्रेसिंग टेबल में एक गुप्त दरवाजा होता है। प्रोग्रामिंग भाषाएं बहुत जटिल परियोजनाएं हैं जिन्हें बिना मुश्किल बारीकियों के जोड़ा जा सकता है।

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


मैं कोटलिन को तीन साल से अधिक समय से लिख रहा हूं, अब केवल उस पर, लेकिन पहले मैंने कोटलिन को मौजूदा जावा परियोजनाओं में खींच लिया। इसलिए, मेरे तरीके से "जावा और कोटलिन को एक साथ कैसे बाँधें" सवाल अक्सर उठता था।

अक्सर जब आप किसी परियोजना में कोटलिन को जोड़ते हैं, तो आप देख सकते हैं कि यह कैसे ...

compile 'rxbinding:xyx' compile 'rxbinding-appcompat-v7:xyx' compile 'rxbinding-design:xyx' compile 'autodispose:xyz' compile 'autodispose-android:xyz' compile 'autodispose-android-archcomponents:xyz' 

... इस में बदल जाता है:

 compile 'rxbinding:xyx' compile 'rxbinding-kotlin:xyx' compile 'rxbinding-appcompat-v7:xyx' compile 'rxbinding-appcompat-v7-kotlin:xyx' compile 'rxbinding-design:xyx' compile 'rxbinding-design-kotlin:xyx' compile 'autodispose:xyz' compile 'autodispose-kotlin:xyz' compile 'autodispose-android:xyz' compile 'autodispose-android-kotlin:xyz' compile 'autodispose-android-archcomponents:xyz' compile 'autodispose-android-archcomponents-kotlin:xyz' 

पिछले कुछ वर्षों की बारीकियों: सबसे लोकप्रिय पुस्तकालयों ने रैपर प्राप्त किए ताकि उन्हें कोटलिन से अधिक मुहावरे से इस्तेमाल किया जा सके।

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

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

तेज धार

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

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

आइए उदाहरण के लिए कल्पना करें कि हम एक समान पुस्तकालय लिखना चाहते हैं, केवल विश्लेषिकी के लिए। भटकाव भी।

 object Analytics { fun send(event: Event) {} fun addPlugins(plugs: List<Plugin>) {} fun getPlugins(): List<Plugin> {} } interface Plugin { fun init() fun send(event: Event) fun close() } data class Event( val name: String, val context: Map<String, Any> = emptyMap() ) 

हम एक ही निर्माण पैटर्न लेते हैं, हमारे पास एक प्रवेश बिंदु है - यह विश्लेषिकी है। हम वहां ईवेंट भेज सकते हैं, प्लगइन्स जोड़ सकते हैं और देख सकते हैं कि हमने वहां क्या जोड़ा है।

प्लगइन एक प्लगइन इंटरफ़ेस है जो एक विशिष्ट विश्लेषणात्मक एपीआई को अमूर्त करता है।

और, वास्तव में, हमारे द्वारा भेजे जाने वाले कुंजी और हमारी विशेषताओं से युक्त घटना वर्ग। यहां रिपोर्ट इस बारे में नहीं है कि क्या यह सिंगलेट्स का उपयोग करने के लायक है, इसलिए चलो एक होलीवर नस्ल नहीं करते हैं, लेकिन हम देखेंगे कि इस पूरी चीज़ को कैसे कंघी करना है।

अब थोड़ा गोता लगाओ। यहाँ कोटलिन में हमारे पुस्तकालय का उपयोग करने का एक उदाहरण है:

 private fun useAnalytics() { Analytics.send(Event("only_name_event")) val props = mapOf( USER_ID to 1235, "my_custom_attr" to true ) Analytics.send(Event("custom_event", props)) val hasPlugins = Analytics.hasPlugins Analytics.addPlugin(EMPTY_PLUGIN) // dry-run Analytics.addPlugins(listOf(LoggerPlugin("ALog"), SegmentPlugin))) val plugins = Analytics.getPlugins() // ... } 

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

अब देखते हैं कि जब हम ऐसा करते हैं तो जावा में क्या होता है:

 private static void useAnalytics() { Analytics.INSTANCE.send(new Event("only_name_event", Collections.emptyMap())); final Map<String, Object> props = new HashMap<>(); props.put(USER_ID, 1235); props.put("my_custom_attr", true); Analytics.INSTANCE.send(new Event("custom_event", props)); boolean hasPlugins = Analytics.INSTANCE.getHasPlugins(); Analytics.INSTANCE.addPlugin(Analytics.INSTANCE.getEMPTY_PLUGIN()); // dry-run final List<EmptyPlugin> pluginsToSet = Arrays.asList(new LoggerPlugin("ALog"), new SegmentPlugin()); // ... } 

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

आइए इवेंट से शुरू करते हैं। हम दूसरी पंक्ति से Colletions.emptyMap () पैरामीटर निकालते हैं, और एक कंपाइलर त्रुटि पॉप अप होती है। इसका क्या कारण है?

 data class Event( val name: String, val context: Map<String, Any> = emptyMap() ) 

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

सभी ट्विस्ट का विश्लेषण करने के लिए हमारा मुख्य उपकरण और कोटलिन एक जेवीएम बायोटेक - कोटलिन बायटेक व्यूअर में कैसे बदल जाता है। Android Studio और IntelliJ IDEA में, यह टूल्स - कोटलिन - शो कोटलिन बायटेकोड मेनू में स्थित है। आप बस Cmd + Shift + A दबा सकते हैं और खोज बार में Kotlin Bytecode टाइप कर सकते हैं।



यहाँ, आश्चर्यजनक रूप से, हम देखते हैं कि हमारा कोटलिन वर्ग क्या बदल रहा है। मैं आपसे बाइटकोड का उत्कृष्ट ज्ञान होने की उम्मीद नहीं करता हूं, और सबसे महत्वपूर्ण बात यह है कि आईडीई डेवलपर्स इसकी उम्मीद नहीं करते हैं। इसलिए, उन्होंने एक बटन Decompile बनाया।

इसे क्लिक करने के बाद, हम ऐसे मोटे तौर पर अच्छे जावा कोड देखते हैं:

 public final class Event { @NotNull private final String name; @NotNull private final Map context; @NotNull public final String getName() { return this.name; } @NotNull public final Map getContext() { return this.context; } public Event(@NotNull String name, @NotNull Map context) { Intrinsics.checkParameterIsNotNull(name, "name"); Intrinsics.checkParameterIsNotNull(context, "context"); super(); this.name = name; this.context = context; } // $FF: Synthetic method public Event(String var1, Map var2, int var3, DefaultConstructorMarker var4) { if ((var3 & 2) != 0) { var2 = MapsKt.emptyMap(); } // ... } 

हम अपने क्षेत्र, गेटर्स, अपेक्षित निर्माणकर्ता को दो मापदंडों के नाम और संदर्भ के साथ देखते हैं, सब कुछ ठीक होता है। और नीचे हम दूसरे निर्माता को देखते हैं, और यहां यह एक अप्रत्याशित हस्ताक्षर के साथ है: एक पैरामीटर के साथ नहीं, लेकिन किसी कारण से चार के साथ।

यहां आप शर्मिंदा हो सकते हैं, लेकिन आप थोड़ी गहराई पर चढ़ सकते हैं और चारों ओर अफरा-तफरी मचा सकते हैं। समझने के लिए, हम समझेंगे कि DefaultConstructorMarker कोटलिन मानक लाइब्रेरी से एक निजी वर्ग है, यहाँ जोड़ा गया है ताकि लिखित निर्माणकर्ताओं के साथ कोई संघर्ष न हो, क्योंकि हम अपने हाथों से DefaultConstructorMarker का पैरामीटर सेट नहीं कर सकते हैं। और इंट var3 के बारे में दिलचस्प बात यह है कि हमें कौन से डिफ़ॉल्ट मानों का उपयोग करना चाहिए। इस मामले में, यदि बिटमैक्स दो से मेल खाता है, तो हम जानते हैं कि var2 सेट नहीं है, हमारी विशेषताएँ सेट नहीं हैं, और हम डिफ़ॉल्ट मान का उपयोग करते हैं।

हम स्थिति को कैसे ठीक कर सकते हैं? ऐसा करने के लिए, पैकेज से एक चमत्कारी एनोटेशन @JvmOverloads है जिसके बारे में मैंने पहले ही बात की थी। हमें इसे कंस्ट्रक्टर पर लटका देना होगा।

 data class Event @JvmOverloads constructor( val name: String, val context: Map<String, Any> = emptyMap() ) 

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

 @JvmOverloads public Event(@NotNull String name) { this.name, (Map)null, 2, (DefaultConstructorMarker)null); } 

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

आइए देखें कि हमें आगे क्या पसंद नहीं है। हमें यह INSTANCE पसंद नहीं है, जो IDEA पर्पल में एक कॉलस है। मुझे बैंगनी रंग पसंद नहीं है :)



आइए देखें कि यह किस वजह से निकला। आइए फिर से बाईटकोड देखें।

उदाहरण के लिए, हम init फ़ंक्शन को हाइलाइट करते हैं और सुनिश्चित करते हैं कि init वास्तव में स्थिर नहीं है।



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

हम देखते हैं कि स्थैतिक कीवर्ड को सार्वजनिक अंतिम init () में जोड़ दिया गया है, और हमने खुद को INSTANCE के साथ काम करने से बचा लिया है। हम इसे जावा कोड में सत्यापित करेंगे।

कंपाइलर अब हमें बताता है कि हम स्थैतिक विधि को INSTANCE के संदर्भ में लागू कर रहे हैं। इसे ठीक किया जा सकता है: Alt + Enter दबाएं, "क्लीनअप कोड" चुनें, और वॉयला, इनस्टांस गायब हो जाता है, सब कुछ उसी के बारे में दिखता है जैसा कि कोटलिन में था:

  Analytics.send(new Event("only_name_event")); 

अब हमारे पास स्थैतिक तरीकों से काम करने की योजना है। यह एनोटेशन जो भी हमारे लिए मायने रखता है:



और टिप्पणी: अगर हमारे पास विधियां स्पष्ट रूप से उदाहरण के तरीके हैं, तो, उदाहरण के लिए, गुणों के साथ सब कुछ इतना स्पष्ट नहीं है। स्वयं फ़ील्ड्स (उदा। प्लगइन्स) स्थैतिक के रूप में उत्पन्न होते हैं। लेकिन गेटर्स और सेटर्स उदाहरण के तरीकों के रूप में काम करते हैं। इसलिए, गुणों के लिए, आपको स्थैतिक और गेटर्स को स्थिर बनाने के लिए इस एनोटेशन को जोड़ना होगा। उदाहरण के लिए, हम isInited variable देखते हैं, इसमें @JvmStatic एनोटेशन जोड़ते हैं, और अब हम Kotlin Bytecode Viewer में देखते हैं कि isInited () विधि स्थिर हो गई है, सब कुछ ठीक है।

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

 public static void useAnalytics() { Analytics.send(new Event("only_name_event")); final Map<String, Object> props = new HashMap<>(); props.put(USER_ID, 1235); props.put("my_custom_attr", true); Analytics.send(new Event("custom_event", props)); boolean hasPlugins = Analytics.getHasPlugins(); Analytics.addPlugin(Analytics.INSTANCE.getEMPTY_PLUGIN()); // dry-run // ... } 

अगला चरण: हम एक बार में दो उपसर्गों के साथ इस नम नाम getHasPlugins पाने वाले को देखते हैं। बेशक, मैं अंग्रेजी भाषा का बहुत बड़ा पारखी नहीं हूं, लेकिन मुझे लगता है कि यहां कुछ और निहित था। ऐसा क्यों हो रहा है?

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

दुर्भाग्य से, हमेशा बूलियन क्षेत्रों से दूर के माध्यम से बुलाया जाना चाहिए। isPlugins काफी संतुष्ट नहीं होगा कि हम क्या नाम से शब्दार्थ दिखाना चाहते हैं। हम कैसे हो?

और यह हमारे लिए मुश्किल नहीं है, इसके लिए हमारी अपनी टिप्पणी है (जैसा कि आप पहले से ही समझ चुके हैं, मैं अक्सर इसे आज दोहराऊंगा)। @JvmName एनोटेशन आपको किसी भी नाम को निर्दिष्ट करने की अनुमति देता है जो हम चाहते हैं (स्वाभाविक रूप से जावा द्वारा समर्थित)। इसे जोड़ें:

 @JvmStatic val hasPlugins @JvmName("hasPlugin") get() = plugins.isNotEmpty() 

आइए देखें कि हमें जावा में क्या मिला: getHasPlugins विधि अब नहीं है, लेकिन hasPlugins अपने आप में काफी कुछ है। इससे हमारी समस्या हल हो गई, फिर से, एक एनोटेशन के साथ। अब हम सभी एनोटेशन को हल करते हैं!

जैसा कि आप देख सकते हैं, यहां हमने एनोटेशन को सीधे गेट्टर पर रखा है। इसका क्या कारण है? इस तथ्य के साथ कि संपत्ति के तहत सब कुछ बहुत कुछ है, और यह स्पष्ट नहीं है कि @JvmName क्या लागू होता है। यदि आप एनोटेशन को वैल हैप्लगिन्स में स्थानांतरित करते हैं, तो कंपाइलर को यह समझ में नहीं आएगा कि इसे किस पर लागू किया जाए।

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

 @get:JvmName("hasPlugins") @JvmStatic val hasPlugins get() = plugins.isNotEmpty() 

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

अगला बिंदु जो हमें थोड़ा भ्रमित करता है, वह है "Analytics.INSTANCE.getEMPTY_PLUGIN ()"। यहाँ बात अब अंग्रेजी में भी नहीं है, लेकिन बस: क्यों? उत्तर उसी के बारे में है, लेकिन पहले एक छोटा सा परिचय।

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

लेकिन यदि आप एक ऐसी वस्तु से एक स्थिरांक बनाना चाहते हैं जो स्ट्रिंग से अलग है, तो आप इसके लिए शब्द कांस्ट का उपयोग नहीं कर पाएंगे। यहाँ हमारे पास EMPTY_PLUGIN = EmptyPlugin () है, इसके अनुसार, यह भयानक गटर स्पष्ट रूप से उत्पन्न होता है। हम एनोटेशन के साथ @ जेएमएननेम का नाम बदल सकते हैं, इसे हटा सकते हैं उपसर्ग प्राप्त करें, लेकिन फिर भी यह एक विधि बनी हुई है - कोष्ठक के साथ। इसलिए, पुराने समाधान काम नहीं करेंगे, हम नए की तलाश कर रहे हैं।

और यहां इसके लिए एनोटेशन @JvmField, जो कहता है: "मुझे यहां गेटर्स नहीं चाहिए, मुझे सेटर्स नहीं चाहिए, मुझे एक फील्ड बनाओ।" इसे Val EMPTY_PLUGIN के सामने रखें और सत्यापित करें कि सब कुछ सत्य है।



Kotlin Bytecode Viewer उस हाइलाइट किए गए टुकड़े को दिखाता है जिस पर आप वर्तमान में फ़ाइल में खड़े हैं। अब हम EMPTY_PLUGIN पर खड़े हैं, और आप देखते हैं कि यहाँ कुछ प्रकार के इनिशियलाइज़ेशन को कंस्ट्रक्टर में लिखा गया है। तथ्य यह है कि गेटटर अब नहीं है और उस तक पहुंच केवल रिकॉर्डिंग के लिए है। और यदि आप विघटित करते हैं, तो हम देखते हैं कि "सार्वजनिक स्थैतिक अंतिम EmptyPlugin EMPTY_PLUGIN" दिखाई दिया है, यह वही है जो हमने हासिल किया है। अच्छा लगा। हम जांचते हैं कि सब कुछ सभी को प्रसन्न करता है, विशेष रूप से, संकलक। सबसे महत्वपूर्ण बात यह है कि आपको अपील करने की आवश्यकता है संकलक।

जेनेरिक्स

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

भिन्नता बुनियादी प्रकार से व्युत्पन्न के लिए एक प्रकार की पदानुक्रम के बारे में जानकारी स्थानांतरित करने का एक तरीका है, उदाहरण के लिए, कंटेनरों या जेनरिक के लिए। यहां हमारे पास पशु और कुत्ते की कक्षाएं बहुत स्पष्ट कनेक्शन के साथ हैं: कुत्ता एक उपप्रकार है, पशु एक उपप्रकार है, तीर उपप्रकार से आता है।



और उनके डेरिवेटिव का क्या कनेक्शन होगा? आइए कुछ मामलों को देखें।

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

हमारी स्थिति में, केवल एक चीज जो Iterator करती है वह हमें टाइप की गई वस्तुएं देती है, उदाहरण के लिए, Animal। यदि हम इटरेटर को कहीं स्वीकार करते हैं, तो हम इटरेटर को वहां रख सकते हैं, और अगली () विधि से एनिमल प्राप्त कर सकते हैं, क्योंकि कुत्ता भी एनिमल है। हम कम नहीं, बल्कि अधिक प्रदान करते हैं, क्योंकि एक कुत्ता एक उपप्रकार है।



मैं दोहराता हूं: हम केवल इस प्रकार से पढ़ रहे हैं, इसलिए, प्रकार और उपप्रकार के बीच संबंध यहां संरक्षित है। और ऐसे प्रकारों को सहसंयोजक कहा जाता है।

एक और मामला: कार्रवाई। एक्शन एक ऐसा फंक्शन है जो कुछ भी नहीं देता है, एक पैरामीटर लेता है, और हम केवल एक्शन को लिखते हैं, अर्थात यह हमसे एक कुत्ता या जानवर लेता है।



इस प्रकार, अब हम प्रदान नहीं करते हैं, लेकिन मांग करते हैं, और हमें कोई और मांग नहीं करनी चाहिए। इसका मतलब है कि हमारी निर्भरता बदल रही है। "और नहीं" हमारे पास पशु (एक कुत्ते से कम जानवर) है। और ऐसे प्रकारों को कंट्राविरेंट कहा जाता है।

एक तीसरा मामला है - उदाहरण के लिए, ArrayList, जिसमें से हम पढ़ते हैं और लिखते हैं। इसलिए, इस मामले में, हम नियमों में से एक का उल्लंघन करते हैं, हमें एक रिकॉर्ड (एक कुत्ते, एक जानवर नहीं) के लिए अधिक आवश्यकता होती है। इस प्रकार के किसी भी तरह से संबंधित नहीं हैं, और उन्हें अपरिवर्तनीय कहा जाता है।



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

कड़वे अनुभव से सीखा है कि यह नहीं किया जा सकता है, जब जेनेरिक डिजाइनिंग करते हैं, तो उन्होंने फैसला किया "हम संग्रह को अपरिवर्तनीय बना देंगे, हम उनके साथ कुछ भी नहीं करेंगे।"

और अंत में यह पता चलता है कि इस तरह की एक स्पष्ट बात में सब कुछ ठीक होना चाहिए, लेकिन वास्तव में ठीक नहीं है:

 // Java List<Dog> dogs = new ArrayList<>(); List<Animal> animals = dogs; 

लेकिन हमें किसी तरह यह निर्धारित करने की आवश्यकता है कि आखिरकार, हम क्या कर सकते हैं: यदि हम केवल इस शीट से पढ़ रहे हैं, तो यहां कुत्तों की सूची को स्थानांतरित करना क्यों संभव नहीं है? इसलिए, वाइल्डकार्ड के साथ चिह्नित करना संभव है कि इस प्रकार की विविधता क्या होगी:

 List<Dog> dogs = new ArrayList<>(); List<? extends Animal> animals = dogs; 

जैसा कि आप देख सकते हैं, यह भिन्नता उपयोग की जगह पर इंगित की जाती है, जहां हम कुत्तों को असाइन करते हैं। इसलिए, इसे उपयोग-साइट संस्करण कहा जाता है।

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

 val dogs: List<Dog> = ArrayList() val animals: List<Animal> = dogs 

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

 interface List<out E> : Collection<E> 

इसे घोषणा-स्थल प्रसरण कहा जाता है। इस प्रकार, हमने एक जगह सब कुछ इंगित किया, और जहां हम इसका उपयोग करते हैं, हम अब इस विषय पर स्पर्श नहीं करते हैं। और यह निशक्त है।

कोड पर वापस जाएं

चलो अपनी गहराई में वापस जाते हैं। यहां हमारे पास AddPlugins विधि है, यह एक सूची लेता है:

 @JvmStatic fun addPlugins (plugs: List<Plugin>) { plugs.forEach { addPlugin(it) } }    ,  , List<EmptyPlugin>, ,     : <source lang="java"> final List<EmptyPlugin> pluginsToSet = Arrays.asList(new LoggerPlugin("Alog"), new SegmentPlugin()); 

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

 @JvmStatic fun addPlugins(plugs: List<@JvmSuppressWildcards Plugin>) { plugs.forEach { addPlugin(it) } } 

SuppressWildcards बोलते हुए, हम इन सभी सवालों को दबा देते हैं, और हमारे हस्ताक्षर वास्तव में बदल जाते हैं। इससे भी अधिक, मैं आपको दिखाता हूँ कि कैसे सब कुछ बाइटकोड में दिखता है:



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



अब हम फिर से एनोटेशन सम्मिलित करते हैं और देखते हैं कि यह बिना पूछताछ के हमारा प्रकार है।



अब हमारा पिछला कोड ठीक से संकलन बंद हो जाएगा क्योंकि हमने वाइल्डकार्ड को काट दिया है। आप अपने लिए देख सकते हैं।

हमने सहसंयोजक प्रकार बनाए। .

, List . , getPlugins, . ? , , , . , Java.

 final List<Plugin> plugins = Analytics.getPlugins(); displayPlugins(plugins); Analytics.getPlugins().add(new EmptyPlugin()); 

, - , , - . , . , - .

. Kotlin , , , , , wildcards Java. , , . , List, Plugin. , , , : Plugin, .

. , , usecase, - , .

, , , - . , Java. Kotlin List — read only-, , Java — ? , List wildcard. , . @JvmWildcard : , . , Java . Java « ?»:



List<? extends Plugin>, « ?» , , . script kiddie, « , , , ArrayList, ». , ArrayList , .

 ((ArrayList<Plugin>) Analytics.getPlugins()).add(new EmptyPlugin()); 

, , , defensive-, - . , , , script kiddies .

 @JvmStatic fun getPlugins(): List<@JvmWildcard Plugin> = plugin.toImmutableList() 

, @JvmSuppressWildcard , , , , .

, . , : .

Java. , :

 @Override public void send(@NotNull Event event) throws IOException 

:

 interface Plugin { fun init() /** @throws IOException if sending failed */ fun send(event: Event) // ... } 

Kotlin checked exception. : . , , . Java -. : « Throws - , »:



-, Kotlin? , …

@Throws, . throws- . , IOExeption:

 open class EmptyPlugin : Plugin { @Throws(IOException::class) override fun send(event: Event) {} // ... } 

:

 interface Plugin { fun init() /** @throws IOException if sending failed */ @Throws(IOException::class) fun send(event: Event) // ... } 

? , Java, exception, . , . , - , , @JvmName. .

, Java . …

 package util fun List<Int>.printReversedSum() { println(this.foldRight(0) { it, acc -> it + acc }) } @JvmName("printReversedConcatenation") fun List<String>.printReversedSum() { println(this.foldRight(StringBuilder()) { it, acc -> acc.append(it) }) } 

, Java , . , IDE . , ? , , , List, List. , type erasure. :



, , top-level c. printReversedSum List, List. Kotlin- , Java- . , kotlin.jvm , Java , , Kotlin . — , concatenation — , .

. . extension- reverse.

 inline fun String.reverse() = StringBuilder(this).reverse().toString() inline fun <reified T> reversedClassName() = T::class.java.simpleName.reverse() inline fun <T> Iterable<T>.forEachReversed(action: (T) -> Unit) { for (element in this.reversed()) action(element) } 

reverse , ReverserKt.

 private static void useUtils() { System.out.println(ReverserKt.reverse("Test")); SumsKt.printReversedSum(asList(1, 2, 3, 4, 5)); SumsKt.printReversedConcatenation(asList("1", "2", "3", "4", "5")); } 

, , . , , Java, - . . ? , @JvmName, , .

, , , , , .

 @file:Suppress("NOTHING_TO_INLINE") @file:JvmName("ReverserUtils") 

Java ReverserKt, , ReverserUtils . « 2.1» — , top-level , . , , sums.kt SumsKt, , reversing ReverserUtils. @JvmName, «ReverserUtils», , , , .

, , « , -». ? @JvmMultifileClass, , , .

"@file:JvmMultifileClass", SumsKt ReverserUtils, — . !

, . , , . , , , @JvmName Kotlin.

Kotlin-

, , . , Kotlin- .

, inline-. Kotlin , , Java ? , , , Java. , , Kotlin-only , dex count limit. Kotlin , .

Reified type parameters. Kotlin, - , Java . Kotlin-only , Kotlin, Java reified, .

java.lang.Class. , Java, . . « Retrofit», ( , ):

 class Retrofit private constructor( val baseUrl: String, val client: Client ) { fun <T : Any> create(service: Class<T>): T {...} fun <T : Any> create(service: KClass<T>): T { return create(service.java) } } 

, Java, , KClass, , extension-, KClass Class, Class KClass ( Kotlin, ).

, . Kotlin- KClass, Reified-, :

 inline fun <reified T : Any> create(): T { return create(T::class.java.java) 

. Kotlin , . val api = retrofit.create(Api::class) val api = retrofit.create<Api>() , ::class . Reified-, -.

Unit. Unit, , void Java, . . , . - Scala, Scala , - , , , void.

Kotlin . Kotlin 22 , - . , , Unit, void, Unit. . , Unit? , . .

 inline fun <T> Iterable<T>.forEachReversed(action: (T) -> Unit) { for (element in this.reversed()) action(element) } 

Kotlin: , method reference, , , .

 private fun useMisc() { listOf(1, 2, 3, 4).forEachReversed(::println) println(reversedClassName<String>()) } 

Java? Java :

 private static void useMisc() { final List<Integer> list = asList(1, 2, 3, 4); ReverserUtils.forEachReversed(list, integer -> { System.out.println(integer); return Unit.INSTANCE; }); 

- , - . Void , . , void, . , , , . , Unit . null, . , .

: Typealiases — , , Kotlin, Java, , , . , - . Java- .

: visibility. , internal visibility. , Kotlin package private, - , public. internal. Internal — , . Retrofit internal- validate.

 internal fun validate(): Retrofit { println("!!!!!! internal fun validate() was called !!!!!!") return this } 

Kotlin, . Java? validate? , , internal public. , Kotlin bytecode viewer.



public, , , , , , API . - 80 , .

Java :

 final Api api = retrofit .validate$production_sources_for_module_library_main() .create(Api.class); api.sendMessage("Hello from Java"); } 

. , , , . , let me explain this to you. , ?

 final Api api = retrofit .validate$library() .create(Api.class); api.sendMessage("Hello from Java"); } 

. « ?» … MAGIC!

, - internal, , API. script kiddie Kotlin Bytecode Viewer, . internal visibility.

, . , , , , SkillsMatter. .

, Kotlin-. , - , . Kotlin bytecode viewer .

धन्यवाद!

, : 8-9 Mobius , . — , .