जावा का नया विकास स्काला और क्लीजुर जैसी भाषाओं के साथ अपनी अंतर-क्षमता को कैसे प्रभावित करेगा?

Question

जहां तक ​​मैं समझता हूं, स्काला और क्लोजर दोनों को नई भाषाओं के रूप में डिजाइन किया गया है

1. जेवीएम पर निर्भर करते हैं, और
2. आसानी से जावा कोड के साथ एकीकृत, इस अर्थ में कि वे स्काला और क्लोजर कोड के अंदर जावा कक्षाओं का उपयोग करने की अनुमति देते हैं।

जावा 8 के साथ शुरू (और शायद जावा के बाद के संस्करणों के साथ और भी मजबूती से), जावा भाषा के शब्दार्थ में बदलाव होंगे।

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

मैं निम्नलिखित परिदृश्यों के बारे में सोच सकता हूं:

1. स्काला या क्लोजर भाषा को नए जावा शब्दार्थ (नए गैर-वस्तु मानों को संभालने के लिए) और जावा के साथ इंटरऑपरेबिलिटी का समर्थन करने के लिए अनुकूलित किया जाएगा।
2. स्काला या क्लोजर भाषा का विस्तार नहीं किया जाएगा। यह केवल तभी संभव होगा जब फ़ंक्शन मूल्यों जैसे नए जावा को मौजूदा अवधारणाओं पर मैप किया जा सकता है। उदाहरण के लिए, स्काला में भी एक फ़ंक्शन एक ऑब्जेक्ट है, इसलिए मुझे लगता है कि जावा फ़ंक्शंस फिर से स्कैला के दृश्य में आने पर कुछ प्रकार की वस्तुओं में लिपटे होंगे।
3. नवीनतम जावा के विकास का पालन किए बिना, स्केल या क्लोजर भाषा जावा 6 या 7 तक इंटरऑपरेबिलिटी का समर्थन करना जारी रखेगी। इसके लिए आवश्यक है कि जावा के पुराने संस्करणों का अभी भी समर्थन किया जाए (कम से कम OpenJDK या किसी अन्य परियोजना द्वारा), ताकि ये भाषाएँ जावा की अधिक रूढ़िवादी / स्थिर शाखा पर आधारित हो सकें।

सारांश: क्या हम उम्मीद कर सकते हैं कि जावा के भविष्य के विकास का जावा के साथ अंतर-संचालन बनाए रखने के लिए स्काला और क्लोजर जैसी भाषाओं पर प्रभाव पड़ेगा? क्या इस विषय पर कुछ चर्चा (लिंक) पहले से चल रही है?

ध्यान दें

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

Comments

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

— किलन फ़ॉथ

@ किलियन फोथ: जहां तक ​​मुझे पता है एक स्काला Stringएक जावा है String। इसलिए स्काला कुछ जावा लाइब्रेरी कक्षाओं का उपयोग करता है। लेकिन अगर आपको लगता है कि यह बहुत मजबूत है, तो मैं सूत्रीकरण को बदल सकता हूं।

— जियोर्जियो

@Kilian Foth: मैं हटा दिया है अवधि निर्भर मेरे सवाल का ध्यान केंद्रित स्काला और जावा resp के बीच अंतर पर नहीं बल्कि इसलिए है क्योंकि। क्लोजर और जावा।

— जियोर्जियो

@KilianFoth यह एक उत्तर होना चाहिए क्योंकि यह प्रश्न की प्रमुख चिंता को संबोधित करता है। किसी भी नए जावा रिलीज़ का नंबर एक लक्ष्य पश्चगामी संगतता है।

— maple_shaft

@maple_shaft: मैंने अपने प्रश्न को सही किया है और "निर्भर" शब्द को हटा दिया है। जैसा कि मैंने एक अन्य टिप्पणी में बताया है, मेरा मुद्दा यह नहीं है कि स्काला या क्लोजर जावा या जेवीएम सुविधाओं पर कैसे निर्भर करता है, लेकिन कैसे स्काला / क्लोजर जावा सुविधाओं को "देख" सकता है। जहाँ तक मुझे पता है कि वे जावा 6 सुविधाओं को देख सकते हैं जैसे कक्षाएं, इंटरफेस, ऑब्जेक्ट, विधियाँ, आदिम डेटा प्रकार। यह स्कैला / क्लोजर जावा 6 कोड का उपयोग (कॉल) करने की अनुमति देता है। मेरा सवाल यह है कि क्या ये भाषाएं "देखें" (और, इसलिए, उपयोग करने में सक्षम) भविष्य की जावा भाषा का निर्माण करती हैं या इसके लिए स्काला / क्लोजर भाषाओं के विस्तार की आवश्यकता होगी?

— जियोर्जियो

Answer 1

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

वास्तव में सबसे बड़ा परिवर्तन करने वाला इंटरोप वास्तव में जावा 7 के साथ आया था - इनवेडेन्क्निक बाइटेकोड के साथ जो जेवीएम के भीतर डायनामिक / लेट बाइंडिंग कॉल की अनुमति देता है - ऐसा कुछ जो शुरू में जेवीएम पर अन्य भाषाओं के लिए डिज़ाइन किया गया था। चूंकि यह लैम्ब्दास के लिए बहुत उपयोगी रूप से अनुकूलित किया गया है, इसलिए जावा 8 के रूप में, जावा वास्तव में इन बायोटेक का उत्सर्जन करना शुरू कर देगा।

कुछ भाषाएं (उदाहरण के लिए JRuby) पहले से ही इनवोकेंडिक का भारी उपयोग कर रही हैं, जबकि अन्य (Scala, Groovy et al) अभी भी इसके उपयोग की जांच कर रहे हैं या इसे पैच करने के शुरुआती चरण में हैं। सिद्धांत रूप में यह उनके गतिशील कॉल को प्रदर्शनकर्ता के रूप में मौजूदा बनाता है। जावा इनवोकैस्टेटिक कॉल, धीमी गति से काम करने वाले असंख्य के विरोध के रूप में जिन्हें वे अतीत में उपयोग करने के लिए मजबूर थे।

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

Comments

लेकिन, जहां तक ​​मुझे पता है, एक स्काला क्लोजर एक ऑब्जेक्ट है।

— जियोर्जियो

हां। स्कैला केवल हाल ही में जावा 1.5 के लिए समर्थन को गिरा दिया, यह 1.6 छोड़ने तक एक लंबा समय होगा।

— जॉर्ग डब्ल्यू मित्तग

@Giorgio जावा की भाषा विशेषताएं वैसे भी असंगत हैं, जैसे कि किसी भी समय संकलित बाइटकोड ट्रिक्स के बराबर हैं। यदि हम स्वीकार करते हैं कि जेवीएम हमेशा पीछे की ओर संगत होगा, भले ही नए बायोटेक पेश किए जाएं, तो स्काला अप्रभावित रहेगा और अपनी सुविधानुसार उन नए जेवीएम सुविधाओं का लाभ उठा सकता है।

— maple_shaft

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

— जियोर्जियो

@ जियोर्जियो: ज़रूर, लेकिन जावा 8 प्लेटफॉर्म के लिए इस तरह के कोई बदलाव की योजना नहीं है। वास्तव में, JVMS को केवल 2003 और 2010 में जावा प्लेटफॉर्म के पूरे इतिहास में दो बार बढ़ाया गया था , और दूसरी बार ( बायटेकोड का परिचय invokedynamic) विशेष रूप से जावा के अलावा अन्य भाषाओं का समर्थन करने के लिए था ; वास्तव में, जावा 7 भाषा उस बाइटकोड का समर्थन या उपयोग नहीं करती है।

— जर्ग डब्ल्यू मित्तग 15

Answer 2

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

executor.execute(() -> { System.out.println("hello world"); });

जावा 8 से स्केल में लिखा जा सकता है:

executor execute new Runnable {
    override def run() { println("hello world") }
}

जब तक आप Scala के () => यूनिट को रननेबल में परिवर्तित करने वाले कुछ रैपर का उपयोग / लिखते नहीं हैं।

Comments

उत्तर के लिए धन्यवाद और मेरे प्रश्न (+1) को संबोधित करने के लिए भी। अगर मैं सही तरीके से समझूं, तो स्काला को अनाम संदर्भों का उपयोग करने के लिए अनाम कक्षाओं का उपयोग एक संदर्भ में जारी रखना होगा, जिसमें जावा 8 लैम्ब्डा का उपयोग करेगा (क्योंकि जावा 8 लैम्ब्डा का स्काला लैम्ब्डा की तुलना में एक अलग शब्दार्थ है)। एक और बिंदु जो मेरे लिए स्पष्ट नहीं है कि एक जावा विधि एक जावा लैम्ब्डा लौटाती है तो क्या होगा। यदि कोई स्काला वर्ग उस विधि को कहता है तो क्या होगा? स्काला में वापसी का प्रकार क्या होगा?

— जियोर्जियो

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

— नरकोदनीलो

@SkyDan: ठीक है, इसलिए स्काला जावा लैम्ब्डा को कुछ इंटरफ़ेस को लागू करने वाली वस्तुओं के रूप में देखेगा। यह बिंदु मेरे लिए स्पष्ट नहीं था: मुझे लगा कि जावा कुछ बाइटकोड उत्पन्न करेगा जो एक वस्तु से अलग था। लेकिन यह हुड के तहत एक वस्तु होना चाहिए, अन्यथा इसे एक इंटरफ़ेस के कार्यान्वयन के रूप में मान्यता नहीं दी जाएगी। मुझे लगता है कि मुझे अब मिल गया है।

— जियोर्जियो

@ जियोर्जियो, अगर आप जावा 8 में लैम्बडा से संबंधित परिवर्तनों के बारे में अधिक जानना चाहते हैं और इन परिवर्तनों को चलाने वाली ताकतों को देखते हैं, तो मैं आपको लैम्बडा प्रोजेक्ट के इस आकर्षक और विस्तृत अवलोकन को पढ़ने की सलाह देता हूं ।

— नरकोदनीलो

@SkyDan: अब इसे पढ़ना। मुझे ऐसा लगता है कि lambdas कर वस्तुओं का प्रतिनिधित्व करते हैं (भले ही प्रकार / इंटरफेस भी संदर्भ में क्यों परिभाषित कर रहे हैं से अनुमान लगाया जाता है)। इसलिए mail.openjdk.java.net/pipermail/lambda-dev/2011-August/… (" लंबोदर वस्तु नहीं हैं") में दी गई जानकारी गलत है या कम से कम, भ्रामक है।

— जियोर्जियो