कोबोल और जावा के शीर्ष स्तर के आर्किटेक्चर के बीच क्या अंतर है?कोबोल से जावा तक पोर्टिंग
प्रोग्रामर जो इन दो भाषाओं में गोद लेते हैं शैलियों और संस्कृतियों क्या हैं?
कोबोल से जावा तक एक सर्वश्रेष्ठ बंदरगाह कैसे हो सकता है?
मैं उपरोक्त वर्णित परियोजना एनएसीए के लिए प्रोजेक्ट लीडर था (कोबोल से 4 लाख लाइनों के लिए कोबोल से जावा तक स्वचालित ट्रांसकोडिंग)।
यदि आपके पास कोई विशिष्ट प्रश्न है, तो कृपया ऊपर वर्णित मेरे आलेख के नीचे एक टिप्पणी के माध्यम से मुझसे संपर्क में रहें।
हमारे पास अच्छी सफलता के साथ हमारे उपकरणों का पुन: उपयोग करने वाली दुनिया भर में कई परियोजनाएं हैं। एनएसीए तकनीक के आधार पर उन परियोजनाओं की जरूरतों को पूरा करने के लिए हम अभी भी नियमित आधार पर उन्हें सुधारते हैं (http://code.google.com/p/naca देखें)।
एक दिलचस्प जॉन सी बर्न द्वारा 'कोबोल प्रोग्रामर के लिए जावा' एक $ 1 (पेपरबैक) के लिए उपलब्ध इस तरह के एक प्रयास में मदद मिल सकती है कि किताब, Theres http://amzn.to/bKqc5j
दोनों मंगलाचरण ढेर आधारित भाषाओं और दोनों समर्थन वस्तु उन्मुख होते हैं और प्रोग्रामिंग की प्रक्रियात्मक शैलियों। हालांकि, यदि आप स्थिर subroutines के साथ एक विशाल मुख्य() विधि में प्रक्रियात्मक कोड को फिर से लिखते हैं तो आपको जावा पर पोर्टिंग का बहुत कम लाभ मिलेगा। आपको भी बहुत कम कोबोल कोड मिलेगा जो भाषा की ऑब्जेक्ट उन्मुख सुविधाओं का लाभ उठाता है।
जैसा कि कोबोल मुख्य रूप से पैसे से जुड़े अनुप्रयोगों के लिए उपयोग किया जाता है, कोबोल की दुकानें और प्रोग्रामर चीजों के व्यावसायिक पक्ष पर अधिक ध्यान केंद्रित करते हैं, चीजों के लेखन-सुरुचिपूर्ण और सुंदर-कोड पक्ष पर कम ध्यान देते हैं। जावा बंदरगाहों के लिए कोबोल मैंने देखा है कि एक वर्ग है, सभी वैरिएबल शीर्ष पर घोषित किए गए हैं क्योंकि स्थैतिक और मुख्य() विधि स्थैतिक तरीकों का एक गुच्छा कॉल करती है जैसे ही पैराग्राफ या कॉल सबप्रोग्राम किया जाता है।
जावा से कोबोल बंदरगाहों को मैंने देखा है कि वे सटीक विपरीत हैं - वे ओओ एक्सटेंशन का उपयोग करते हैं जो अधिकांश कोबोल प्रोग्रामर कभी भी उपयोग नहीं करते हैं।
यदि आप आईबीएम एंटरप्राइज़ कोबोल शॉप में हैं, तो वास्तव में बंदरगाह की आवश्यकता नहीं है। दो भाषाएं अच्छी तरह से संचालित होती हैं और आप जावा के साथ नए हिस्सों को प्रतिस्थापित कर सकते हैं और अभी भी अच्छी तरह से बातचीत कर सकते हैं।
लेकिन कोबोल से जावा तक वास्तव में बंदरगाह का सबसे अच्छा तरीका दोनों भाषाओं और प्रतिमानों को अच्छी तरह से सीखना है; कोबोल सिस्टम की मौजूदा कार्यक्षमता को बहुत विस्तार से दस्तावेज करें; फिर एक नई ओओ स्टाइल जावा सिस्टम डिज़ाइन और लिखें जिसमें उस कार्यक्षमता भी होगी।
आपने जावा-टू-कोबोल पोर्ट देखा है? कहा पे? जबकि संक्षेप में यह दिलचस्प है, मैंने नहीं सोचा था कि कोई वास्तव में ऐसा करेगा। प्रेरणा क्या है? –
प्रेरणा यह है कि लगभग 20 वर्षों के लिए विश्वविद्यालय ओओ-प्रशिक्षित जावा प्रोग्रामर और कोई कोबोल प्रोग्रामर क्रैंकिंग नहीं कर रहे हैं। बीन काउंटर इसे देखते हैं और सोचते हैं कि यह समय बदलने/माइग्रेट/रिपोजिशन/जो कुछ भी है ताकि वे सस्ती प्रतिभा किराए पर ले सकें और वही वर्कलोड पूरा कर सकें। चाहे वह एक साधु रणनीति है या नहीं, एक विषय किसी अन्य धागे के लिए सबसे अच्छा छोड़ दिया गया है। –
इस तथ्य के आधार पर कि विश्वविद्यालय ओओ प्रोग्रामर को क्रैंकिंग कर रहे हैं, मैं समझ सकता हूं (और इसे हर समय सुन सकता हूं) प्रबंधक जो कोबोल को जावा में परिवर्तित करना चाहते हैं। सवाल था, "जावा टू कोबोल"? यह अधिक जावा प्रोग्रामर की उपस्थिति से न्यायसंगत नहीं है ... कम से कम मैंने कभी यह नहीं सुना है, और मैं माइग्रेशन स्पेस में काम करता हूं। –
क्या आप वर्तमान स्थिति को संक्षेप में समझा सकते हैं? ऐसा प्रतीत होता है कि एरिना ने एक बंद स्रोत परामर्श मॉडल पर स्विच किया है। –
एनएसीए पर किसी अन्य परिप्रेक्ष्य के लिए इसे देखें: http://stackoverflow.com/a/1061829/120163 –