क्या आपकी कंपनी जावा से दूसरी तकनीक में बदलाव करने की सोच रही है? [बन्द है]

Question

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

मैं सोच रहा हूं कि क्या ऐसी कंपनियां या संगठन हैं जो बात कर रहे हैं, स्पाइक्स कर रहे हैं या एक अलग तकनीक का उपयोग करना शुरू कर रहे हैं, इस विचार के साथ कि ग्रीन फील्ड प्रोजेक्ट्स के लिए जावा का उपयोग बंद कर दिया जाए, उसी तरह 15 साल पहले कंपनियों ने फॉर्म C ++, perl माइग्रेट किया था और जावा के लिए अन्य प्रौद्योगिकियों। मुझे यह जानने में भी दिलचस्पी है कि यह क्या हो रहा है, उदाहरण के लिए: 2 वर्षों में एक अलग तकनीक पर माइग्रेट करने की योजना।

स्पष्ट होने के लिए, मैं यह नहीं पूछ रहा हूं कि कौन सी तकनीक बेहतर है। मैं पूछ रहा हूं कि क्या आपका संगठन किसी अन्य तकनीक के लिए जावा छोड़ने के बारे में सोच रहा है।

Comments

ग्रूवी और स्काला जेवीएम के आश्रित नहीं हैं? यदि ऐसा है, तो वे भी Oracle से चिंतित हैं जो JVM का मुद्रीकरण करना चाहते हैं।

— POSIX_ME_HARDER

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

— Augusto

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

— मिकेरा

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

— अगस्‍त

Answer 1

बिल्कुल नहीं - वास्तव में मैं अपनी कंपनी में एक प्लेटफॉर्म (डेटा माइनिंग के लिए सास एप्लिकेशन और टूल विकसित करने वाला एक स्टार्टअप) के रूप में जावा में भारी निवेश कर रहा हूं।

यहाँ कारण हैं:

• जावा को एक प्लेटफॉर्म के रूप में चुनने का मतलब यह नहीं है कि आपको जावा को भाषा के रूप में उपयोग करना होगा। हम क्लीजुर को प्राथमिक अनुप्रयोग विकास भाषा के रूप में उपयोग करते हैं, कभी-कभी जावा में जहां जरूरत होती है, गिरते हैं। लेकिन स्केला और ग्रूवी जैसी अन्य JVM भाषाएँ भी बढ़िया हैं।

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

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

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

• ग्रहण एक महान आईडीई है और मजबूत उद्यम अनुप्रयोगों के विकास के लिए एक शानदार टूलकिन प्रदान करता है । हम Maven, JUnit, Git / SVN एकीकरण और अन्य उपकरणों के एक मेजबान का उपयोग करते हैं जो ग्रहण प्लगइन्स के रूप में उपलब्ध हैं। यह सब "बस काम करता है"।

अंत में, अन्य विकल्प क्या हैं?

• .NET केवल तुलनात्मक क्षमताओं वाला एकमात्र प्लेटफॉर्म है और मुझे व्यक्तिगत रूप से C # पसंद है, लेकिन यह आपको Microsoft तकनीकों (Oracle / IBM IMHO से भी बदतर) में लॉक करता है और इसमें ओपन-सोर्स इकोसिस्टम की समान चौड़ाई नहीं है। Microsoft दुकानों के लिए ठीक है, लेकिन यदि आप अपनी खुद की तकनीकी नियति को नियंत्रित नहीं करना चाहते हैं। और हां, मोनो प्यारा है, लेकिन मैं अपने व्यवसाय को एक ऐसे प्लेटफॉर्म पर दांव पर नहीं लगा सकता, जो .NET मेनस्ट्रीम के साथ संगतता के कार्य स्तर को बनाए रखने में सक्षम हो या न हो।

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

• C / C ++ सिस्टम प्रोग्रामिंग और गेम्स के लिए बहुत अच्छा है, लेकिन आधुनिक वेब एप्लिकेशन डेवलपमेंट के लिए बहुत जटिल / महंगा / अनम्य है।

• और फिर वहाँ सुंदर भाषाएँ हैं जो मुझे हास्केल की तरह पसंद हैं, जो अकादमिक दृष्टिकोण से शानदार हैं, लेकिन उनके पास एक विश्वसनीय मंच विकल्प बनाने के लिए बस उद्योग को अपनाने / पारिस्थितिकी तंत्र की आवश्यकता नहीं है। इसके अलावा, मैं JVM पर क्लीजुर चलाकर आधुनिक कार्यात्मक प्रोग्रामिंग के अधिकांश लाभ प्राप्त कर सकता हूं ....।

तो हाँ, यह एक जटिल निर्णय है। लेकिन मैंने काफी शोध और विचार के बाद अन्य सभी विकल्पों के ऊपर जावा निर्णय लिया। मैं आज भी वही फैसला करूंगा।

अपडेट करें

भाषा विकल्प के रूप में जेवीएम पर क्लोजर की पसंद के बारे में कुछ शब्द। इसके लिए मुख्य प्रेरणाएँ थीं:

• Concurrency - क्लोजर की एक अनूठी संगोष्ठी कहानी है, जो इस वीडियो को देख रही है, जिसमें कुछ मुख्य अवधारणाओं का वर्णन है। यह सॉफ्टवेयर ट्रांजैक्शनल मेमोरी का उपयोग करके बड़े पैमाने पर मल्टी-कोर आर्किटेक्चर के लिए मज़बूती से स्केल कर सकता है । और यह बहुत ज्यादा ओवरहेड (लॉक-फ्री!) के बिना ऐसा करने का प्रबंधन करता है, जो इंजीनियरिंग का एक बहुत बड़ा कारनामा है।
• कार्यात्मक प्रोग्रामिंग - क्लोजर एक कार्यात्मक भाषा है जो अपरिवर्तनीयता और उच्च क्रम कार्यों पर जोर देती है। यह हास्केल के रूप में विशुद्ध रूप से कार्यात्मक नहीं है, लेकिन यह पहली और एक एफपी भाषा है। कुछ लोग कहते हैं कि इससे आपको बेहतर कार्यक्रम लिखने में मदद मिलती है।
• प्रोग्रामर उत्पादकता - क्लीजुर को लिस्प कोड-इस-डेटा दर्शन के सभी उत्पादकता लाभ मिलते हैं। व्यवहार में इसका मतलब अविश्वसनीय रूप से शक्तिशाली मैक्रो क्षमताओं, और सरल लेकिन बेहद लचीली वाक्य रचना है जिसका उपयोग आप किसी भी समस्या से निपटने के लिए अपने स्वयं के डीएसएल को परिभाषित करने के लिए कर सकते हैं।
• तेजी से विकास और पटकथा के लिए उपयुक्त एक गतिशील भाषा की आवश्यकता है - क्लोजर का उपयोग मानक बिल्ड-टेस्ट-टेस्ट-तैनाती चक्र में किया जा सकता है, लेकिन वास्तव में आरईपीएल का उपयोग करना स्वाभाविक रूप से अधिक स्वाभाविक रूप से विकसित होता है, जो चल रहे कोड वातावरण को संशोधित करता है। उदाहरण के लिए, मैं इंकैटर का उपयोग ग्राफ को प्लॉट करने में सक्षम होने और मक्खी पर डेटा की कल्पना करने के लिए करता हूं क्योंकि मैं बैच रन के परिणामों को देखने के लिए विकसित करता हूं।
• जावा इंटरऑपरेबिलिटी - क्लोजर का जावा इंटरोप बहुत प्रभावी है। क्लॉज्योर ऑब्जेक्ट जावा ऑब्जेक्ट्स हैं और इसके विपरीत, इसलिए जब भी आपको आवश्यकता हो, तो जावा एपीआई और लाइब्रेरी को कॉल करना तुच्छ है। यह आपको पुस्तकालयों और उपकरणों के पूरे जावा पारिस्थितिकी तंत्र के सभी लाभ प्रदान करता है।
• अच्छा समुदाय - क्लोजर का समुदाय छोटा लेकिन गतिशील, मैत्रीपूर्ण और तेजी से बढ़ रहा है। महान खुला स्रोत जैसे पहले से ही परियोजनाओं, बहुत से Incanter (सांख्यिकीय कंप्यूटिंग) या अंगूठी / Compojure (वेब सर्वर ढांचा) या वामावर्त (ग्रहण आईडीई प्लगइन)

Comments

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

— अगस्‍त

निश्चित रूप से, मैंने इस बारे में कुछ टिप्पणी जोड़ दी है कि क्लोजर विशेष रूप से क्यों है (मैंने स्काला पर भी विचार किया जो बहुत आशाजनक था, लेकिन

— क्लीजुर

आपकी कंपनी ने क्लोजर का उपयोग करने का निर्णय क्यों लिया, इसके बारे में स्पष्टीकरण के लिए धन्यवाद!

— अगस्तो

Answer 2

यह सब ग्राहक पर निर्भर करता है।

जावा का हमेशा अपना एक छोटा सा स्थान होता है जहां लोग एक या दूसरे कारणों से, केवल उन्हीं कारणों से, जो लोग .php या .net पर जाते हैं, के लिए इसे करने जा रहे हैं, लेकिन अंततः यह ग्राहक की आवश्यकताओं और पसंद पर निर्भर करता है।

यदि कोई ग्राहक कहता है ... मैं चाहता हूं कि यह आवेदन जावा में हो ... तो क्या हम नहीं कहने वाले हैं? शायद नहीं ... अगर वे कहते हैं कि हम वास्तव में परवाह नहीं करते हैं .... क्या हम इसे जावा में लिखने जा रहे हैं? शायद नहीं, लेकिन यह सिर्फ अटकलें हैं।

हमारे पास जावा में लिखे गए एप्लिकेशन हैं जिनका एक लंबा इतिहास है, लेकिन ऐसा प्रतीत होता है कि ग्राहक सावधानीपूर्वक खिड़कियों के ब्रांड के साथ हर जगह बदल रहा है .... sql सर्वर को oracle ... सर्वर 2008 के साथ unix / linux ... और php और जावा .net के साथ

अगर ऐसा होता है, तो हाँ ... जब तक कोई नया ग्राहक नहीं आता है और कहता है कि अरे ... हम चाहते हैं कि यह जावा में लिखा है ... हम इसका उपयोग कर रहे हैं।

Comments

एक बड़ी अमेरिकी कार रिटेलर कुछ ऐसा ही कर रही है, यह जावा के बजाय रूबी में अधिकांश ग्रीनफील्ड परियोजनाओं का निर्माण शुरू कर रही है।

— अगस्तो

Answer 3

पहले एक आधार, मैं एक सॉफ्टवेयर कंपनी में काम नहीं करता।

ठीक है, हम अपने सभी महत्वपूर्ण सूचनाओं के साथ Oracle को अपने मुख्य डेटाबेस के रूप में उपयोग करते हैं। इस वजह से, हम Oracle के साथ कुछ भी करने के लिए जावा का उपयोग जारी रखने की योजना बनाते हैं। ओरेकल का सन का अधिग्रहण हमारे लिए एक बढ़ावा है कि हम ओरेकल से संबंधित किसी भी चीज के लिए जावा का उपयोग जारी रखें।

लेकिन, कोई भी डेस्कटॉप एप्लिकेशन C # में लिखे गए हैं क्योंकि सब कुछ विंडोज आधारित है।

Answer 4

क्या आपकी कंपनी जावा से दूसरी तकनीक में बदलाव करने की सोच रही है?

सवाल का जवाब देने के लिए। नहीं।

जैसा कि हर जावा डेवलपर जानता है ...

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

... जावा का भविष्य काफी अस्पष्ट लग रहा है, विशेष रूप से क्योंकि ओरेकल जेवीएम का मुद्रीकरण करना चाहता है।

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

जावा के रूप में एक भाषा भी पिछले कुछ वर्षों में बासी हो गई है, क्लोजर का गैर-समावेश एक उदाहरण है (जो जावा 1.8 में शामिल हो सकता है)।

यह डेवलपर्स को परेशान कर सकता है, लेकिन "गतिहीनता" वास्तव में सन / ओरेकल का परिणाम है जो व्यवसाय चाहता है पर ध्यान दे रहा है ... एक भाषा / मंच जो दीर्घकालिक स्थिरता के साथ है।

इसी समय, कुछ नई तकनीकों जैसे कि रूबी, स्काला और ग्रूवी का उपयोग जटिल साइटों को वितरित करने के लिए किया जा रहा है।

फिर, प्रबंधन के दृष्टिकोण से जूरी इस बात पर बाहर है कि क्या ये प्रौद्योगिकियाँ बोर्ड भर में बेहतर हैं।

• क्या दावा किया गया है कि उत्पादकता में दीर्घावधि में वास्तव में वृद्धि होती है ?
• क्या वहां प्रदर्शन अभी तक जारी है? अनुमापकता? थर्ड पार्टी टूल और लाइब्रेरी?
• क्या वे अनुभवी कर्मचारियों की भर्ती कर सकते हैं?

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

Comments

@ अगुस्तो - मैंने आपके प्रश्न का उत्तर दिया है; पहले वाक्य देखें क्या आप अब खुश हैं?

— स्टीफन सी