अपने प्रोजेक्ट में जावा से स्काला तक कैसे जाएं

सभी को नमस्कार।
समय-समय पर जावा डेवलपर्स से जिन्होंने स्काला के अस्तित्व के बारे में सीखा, सवाल "मौजूदा जावा प्रोजेक्ट में स्काला का उपयोग कैसे शुरू करें? क्या एक से दूसरे में जाना मुश्किल है? इसमें कितना समय लगेगा? मालिकों को कैसे मनाएँ? ”हमारी परियोजना में, ऐसा संक्रमण हुआ, आज लगभग पूरी परियोजना पहले से ही स्काला में है, इसलिए मैंने व्यंजनों और छापों को साझा करने का निर्णय लिया।

यह सब कैसे शुरू हुआ, यह "मुझे इसकी आवश्यकता क्यों है?"

1. मैं उत्पादन में कुछ नया और उपयोगी सीखना चाहता था;
2. मैं जावा में कई पत्र लिखने से थक गया हूं, लेकिन मैं सब कुछ पूरी तरह से फिर से लिखना नहीं चाहता, पायथन में कहते हैं;

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

इसमें कितना समय लगेगा?

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

मौजूदा जावा प्रोजेक्ट में स्काला का उपयोग कैसे शुरू करें?

सबसे पहले, माता-पिता pom.xml में स्काला समर्थन जोड़ें:

<project> ... <properties> <version-scala>2.10.3</version-scala> </properties> <dependencies> <dependency> <groupId>org.scala-lang</groupId> <artifactId>scala-library</artifactId> <version>${version-scala}</version> </dependency> </dependencies> <build> <pluginManagement> <plugins> <plugin> <groupId>net.alchim31.maven</groupId> <artifactId>scala-maven-plugin</artifactId> <version>3.1.6</version> <configuration> <scalaVersion>${version-scala}</scalaVersion> <args> <arg>-deprecation</arg> <arg>-explaintypes</arg> <arg>-feature</arg> <arg>-optimise</arg> <arg>-unchecked</arg> </args> </configuration> <executions> <execution> <id>scala-compile</id> <phase>process-resources</phase> <goals> <goal>add-source</goal> <goal>compile</goal> </goals> </execution> <execution> <id>scala-compile-tests</id> <phase>process-test-resources</phase> <goals> <goal>testCompile</goal> </goals> </execution> </executions> </plugin> </plugins> </pluginManagement> <plugins> <plugin> <groupId>net.alchim31.maven</groupId> <artifactId>scala-maven-plugin</artifactId> </plugin> </plugins> </build> </project> 

इसके अलावा ... और हालांकि, यह सब नहीं है।
अब mvan mvn compile सभी ssc / main / scala में स्थित .scala स्रोतों को एकत्रित करेगा (हालाँकि, src / main / java में स्थित लोगों को भी एकत्र किया जाएगा)। आप स्केल में JUnit परीक्षण भी लिख सकते हैं और mvn test चला सकते हैं। इस प्लगइन के लिए एक महत्वपूर्ण नोट: mvn test केवल उन .scala परीक्षणों को इकट्ठा करेगा और निष्पादित करेगा जो src / test / scala में निहित हैं, अन्यथा उन्हें पूरी तरह से अनदेखा कर दिया जाएगा । इसलिए, तुरंत अपने .scala को src / (main | test) / scala / में डालें। ग्रैडल के लिए, जहां तक ​​मुझे पता है, स्काला समर्थन के साथ कोई समस्या नहीं है।

सामान्यतया, हाल ही में एसबीटी (सिंपल बिल्ड टूल, अनिवार्य रूप से ग्रेडल की तरह, केवल स्काला पर) स्काला परियोजनाओं के लिए वास्तविक मानक बन गया है। मेरी राय में SBT पर स्विच करने से समझ में आएगा जब आपको ScalaTest, ScalaCheck, Specs इत्यादि की आवश्यकता होती है, क्योंकि SBT उनके साथ मूल रूप से एकीकृत करता है, लेकिन कोई भी उन्हें आप पर थोपता नहीं है। हमने एसबीटी पर स्विच नहीं किया है, इसके फायदे अभी तक परियोजनाओं की संरचना और उनके कॉन्फ़िगरेशन को हिला देने की आवश्यकता से आगे नहीं बढ़े हैं।

IDE के लिए, हम IntelliJ IDEA में काम करते हैं, और इसमें यह सेटिंग्स में स्काला समर्थन को सक्षम करने के लिए पर्याप्त है (फ़ाइल → सेटिंग्स → प्लगइन्स → चेक स्काला)। सभी मॉड्यूल के लिए रिबूट करने के बाद, पोम से कॉन्फ़िगर किए गए स्कैला पहलू को जोड़ा जाएगा, और मावेन के बिना खुद ही आईडिया का निर्माण करना संभव होगा। इसके अलावा, यदि आप जावा से स्केल तक कुछ वर्ग को फिर से लिखना चाहते हैं, तो IDEA में .java फ़ाइलों के लिए मेनू में, "कन्वर्ट करने के लिए" स्केल आइटम में बदलने की क्षमता है, या बस .java खोलने और Ctrl-Shift-G दबाकर। जावा स्रोत कोड यथावत रहेगा, जो परिवर्तित कोड की तुलना और जोड़ने के लिए एक संदर्भ के रूप में उपयोगी है, फिर आपको इसे हटाने की आवश्यकता है)। ग्रहण के लिए, एक संगत प्लगइन है ।

क्या एक से दूसरे में जाना मुश्किल है?

हमारे लिए, उत्तर "नहीं" था, लेकिन बिना किसी कठिनाई के:

• for(;;) और break की अनुपस्थिति के मद्देनजर break कुछ जटिल छोरों को अच्छी तरह से तैयार करना आवश्यक था। हालांकि, यह केवल लाभ हुआ, क्योंकि कोड क्लीनर और अधिक समझ में आया। break को अस्थायी रूप से scala.util.control.Breaks का उपयोग करके मुआवजा दिया जा सकता है;
• कभी-कभी स्केला में समृद्ध प्रकार-प्रणाली के मद्देनजर जावा से स्काला का उपयोग करना मुश्किल था, या कार्यान्वयन के साथ स्काला लक्षण के जावा एनालॉग्स की अनुपस्थिति, या चेक किए गए अपवादों की अनुपस्थिति (स्काला कोड में, संकलक एक पक्षपातपूर्ण के रूप में चुप हो जाएगा, लेकिन जावा कोड को मजबूर करने के लिए कहेंगे देखें, @throws[SomeException] में एक एनोटेशन @throws[SomeException] , जो कंपाइलर को @throws[SomeException] साथ बाइटकोड उत्पन्न करने के लिए कहता है);
• काफी जटिलता नहीं है, संसाधनों के साथ कोई प्रयास नहीं है (जावा 7 वाले लोगों के लिए), जो हालांकि ऋण पैटर्न द्वारा आसानी से बदल दिया जाता है, अर्थात, प्रपत्र का एक फ़ंक्शन ...

 //        ru.blablabla…,    « »     ru package object ru { //      http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.20.3.1 //   [A <: AutoCloseable]  [A <: { def close() }],         close,     def using[A <: AutoCloseable, R](resource: A)(block: A => R): R = { var primary: Throwable = null try { block(resource) } catch { case ex: Throwable => primary = ex // to allow suppresing throw ex } finally if (resource ne null) { if (primary eq null) { resource.close() } else try { resource.close() } catch { case ex: Throwable => primary.addSuppressed(ex) } } } } 

जिसके बाद आप इसे कोड में उपयोग कर सकते हैं

 package ru.habrahabr.hello ... val maybeSomeResult = using (Files.newBufferedReader(…)) { reader => // use reader and maybe return some result } ... 

अधिकारियों को कैसे मनाएं?

मैं स्काला को गाने नहीं जा रहा हूँ, मैं केवल प्राप्त वास्तविक लाभांश का वर्णन करूँगा:

• काफी कम अक्षर। विशेष रूप से, हमारी परियोजना में, कुछ त्वरित मोड़ के साथ स्रोत के एक साधारण रूपांतरण ने भी लाइनों की संख्या में 25% की औसत से कमी की अनुमति दी, और सामान्य तौर पर 37 हजार में से लगभग 9 हजार लाइनें खो गईं। ये रेखाएँ हैं, अक्षर स्वयं भी छोटे हो गए हैं। जाहिर है, कम पत्रों का मतलब है कि हम कार्यों को तेजी से हल करते हैं और त्रुटियों को अधिक आसानी से पाते हैं। एक पंक्ति पर कक्षाएं लिखने की क्षमता आमतौर पर पहले छत को उड़ा देती है;
• तरीकों की एक गुच्छा के साथ एक समृद्ध संग्रह पुस्तकालय ने लूप के साथ नियमित काम की एक बड़ी मात्रा को बचाया। ये सभी मानचित्र फ़िल्टर फोर्ल में मौजूद मिन पार्स आदि हैं। आदि जावा में वापसी के संकेत बस मारे जाते हैं (केवल बराबर मूल्य क्या है)। यह सभी धन अपरिवर्तनीय संग्रहों द्वारा पूरित है, जो कि Iterable में कमी है (जिसमें Iterable कोई आकार नहीं है, Collection पहले से ही है, Collections.unmodifiable… केवल मूर्ख के खिलाफ सुरक्षा को जोड़ते हैं लेकिन दुरुपयोग से रक्षा नहीं करते हैं)। मेरी राय में, यहां तक ​​कि इस पुस्तकालय की खातिर यह स्काला की खोज के लायक है (हालांकि, जेडीके में उत्पादक समवर्ती संग्रह का एक विस्तृत चयन है);
• कोड की अभिव्यक्ति बढ़ गई है, विशेष रूप से अक्सर हम Option[T] उपयोग करते हैं जो सरलतम मामले में अशक्त जांच (रीड, संबंधित बग) की समस्या को हल करता है;
• उच्च क्रम के कार्य और स्काला के अन्य कार्यात्मक घटक फिर से आपको छोटे, अधिक अभिव्यंजक और पुन: प्रयोज्य कोड लिखने की अनुमति देते हैं (जावा 8 में, लैम्ब्डा निश्चित रूप से एक छोटा सा सांत्वना होगा, लेकिन उन्हें अभी भी इंतजार करना होगा);
• मॉडरेशन में निहित रूपांतरणों ने हमें सभी प्रकार की रैपिंग कक्षाओं के साथ कोड को अव्यवस्थित करने से बचने की अनुमति दी;
• == स्काला में यह जावा में Objects.equals(o1, o2) तरह है, लिंक की यादृच्छिक तुलना को अलविदा (हालांकि यदि यह आवश्यक है, तो वहाँ eq और neq );
• जावा के साथ अच्छी बातचीत स्काला डिजाइन की नींव में निहित है, इसलिए सभी प्रकार के जावा फ्रेमवर्क (स्प्रिंग, हाइबरनेट, आदि) का एकीकरण बहुत दर्द रहित है। उदाहरण के लिए, @BeanProperty तरह एनोटेशन का एक गुच्छा है, जो संकलक को क्षेत्र के लिए जावाबीन शैली में @BeanProperty जनरेट करने के लिए कहता है।

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

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

पुनश्च: एक राय है कि स्काला जटिल है और अधिकांश जावा डेवलपर्स ( हब्रहे पर अनुवाद के लिए habrahabr.ru/post/134897 देखें) में फिट नहीं है, लेकिन मेरी राय में स्काला में एक इनपुट थ्रेशोल्ड है जो छोटा है, भाषा आपको अपना सिर पूल में और अच्छी तरह से फेंकने नहीं देती है। व्यावहारिक उपयोग से पहले इसका अध्ययन करें, लेकिन यह जल्दी से पर्याप्त लाभ ला सकता है।

उपयोगी संसाधन:

• स्काला वेबसाइट पर सूचीबद्ध किताबें, मैं विशेष रूप से "स्केल इन एक्शन" का उल्लेख करता हूं, जिसमें सिद्धांतों की तुलना में हर रोज अधिक व्यावहारिक उदाहरण हैं;
• आईबीएम से स्काला श्रृंखला के लिए व्यस्त जावा डेवलपर का गाइड
• स्काला मावेन प्लगइन ;
• SBT ;
• ट्विटर से प्रभावी स्काला ;
• YouTube पर लिंक्डइन पर स्कैला उपयोग
• शुरुआती और अधिक कठिन के लिए कोर्सेरा पाठ्यक्रम;
• DZone पर स्काला की ओर पलायन का एक और प्रभाव।