क्या प्रोजेक्ट लोम्बोक का उपयोग करना सुरक्षित है? [बन्द है]


436

यदि आप नहीं जानते हैं कि प्रोजेक्ट लोम्बोक जावा के कुछ झुंझलाहटों के साथ सामान उत्पन्न करने में मदद करता है जैसे गेटर्स जेनरेट करना और एनोटेशन के साथ बसना और यहाँ तक कि @Data के साथ जेनरेशन जैसी सरल JavaBean । यह वास्तव में मेरी मदद कर सकता है, विशेष रूप से 50 अलग-अलग घटना वस्तुओं में जहां आपके पास 7 अलग-अलग फ़ील्ड हैं जिन्हें निर्माण करने और गेटर्स के साथ छिपाने की आवश्यकता है। मैं इसके साथ लगभग एक हजार लाइनों का कोड हटा सकता था।

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

तो: क्या किसी भी परियोजना पर, छोटे या बड़े पर लोमबोक का उपयोग करना सुरक्षित है? क्या सकारात्मक प्रभाव नकारात्मक के लायक हैं?


5
Add jdk9 संकलक समर्थन # 985 मेरी टिप्पणी के समय अनसुलझा है। जावा 9 के पैकेज सिस्टम javacको आंतरिक sun.*कक्षाओं ((
gavenkoa

1
हो सकता है कि दिलचस्प: medium.com/@gabor.liptak/...
Gábor Lipták

इन दिनों परियोजनाएं इस तरह की चीजों को करने के लिए javac में निर्मित एनोटेशन प्रीप्रोसेसर का उपयोग करती हैं - यह तंत्र मानक है और इसे जानने के लिए अच्छे प्रोग्रामर से उम्मीद की जा सकती है।
थोरबजोरन रावन एंडरसन

जवाबों:


181

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

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

आप इन संभावित मुद्दों का उल्लेख करते हैं:

जब मैं इसका उल्लेख करूँगा तो ## जावा फ़्रीनोड चैनल में फ़्लेमवर्स फूटेंगे

आसान। फ्लैमवार्स में ध्यान न दें / भाग न लें, या केवल लोम्बोक का उल्लेख करने से बचें।

कोड स्निपेट उपलब्ध कराने से संभावित सहायकों को भ्रमित किया जाएगा,

यदि परियोजना की रणनीति लोम्बोक का उपयोग करना है, तो संभावित सहायकों को इसका उपयोग करने की आवश्यकता होगी।

लोग गुम जावाडॉक की शिकायत करेंगे,

यही उनकी समस्या है। उनके सही दिमाग में कोई भी उनके संगठन के स्रोत कोड / प्रलेखन नियमों को तीसरे पक्ष के ओपन सोर्स सॉफ़्टवेयर पर सख्ती से लागू करने की कोशिश नहीं करता है। प्रोजेक्ट टीम प्रोजेक्ट स्रोत कोड / प्रलेखन मानकों को सेट करने के लिए स्वतंत्र होना चाहिए जो कि उपयोग की जा रही तकनीक के लिए उपयुक्त हैं।

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

और भविष्य के कमिटर्स इसे वैसे भी हटा सकते हैं।

यह नहीं है! यदि सहमत परियोजना की रणनीति लोम्बोक का उपयोग करने के लिए है, तो कोड को मंज़ूर करने वाले कमिटर्स का पीछा किया जाना चाहिए, और यदि आवश्यक हो तो उनके प्रतिबद्ध अधिकारों को वापस ले लिया जाना चाहिए।

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


77
एक लोम्बोक डेवलपर के रूप में, मैं कह सकता हूं कि जेवाडोक का निर्माण तकनीकी रूप से संभव है। यदि आप इसे लागू करने के बारे में कोई उज्ज्वल विचार रखते हैं, तो कृपया Google समूह में भाग लें। मेरा मतलब है, बस एक मानक पाठ उत्पन्न करना उतना उपयोगी नहीं है। जैसे getFoo, रिटर्न फू, setFoo सेट फू? कैसे मदद करने जा रहा है?
रोयल स्पिलकर

177
मैं कहूंगा कि सेम गेटर्स / सेटर्स के लिए javadoc अच्छे से अधिक नुकसान करता है। वे विधियां एक अच्छी तरह से समझे गए सम्मेलन का पालन करती हैं जिन्हें जावदोक में जोड़ने की आवश्यकता नहीं होती है; यह सिर्फ शोर में जोड़ता है। जब वे अनपेक्षित रूप से कुछ करते हैं और उनके साइड-इफ़ेक्ट होते हैं, तो केवल पाने और बसने के लिए दस्तावेज़ जोड़ें।
गैरीएफ

9
मुझे बस एहसास हुआ कि javadoc टिप्पणी इस तथ्य को संदर्भित कर सकती है कि यदि आप अपने lomboked कोड के लिए javadoc उत्पन्न करते हैं, तो गेटर्स और सेटर बिल्कुल दिखाई नहीं देते हैं। ठीक करने का तरीका यह है कि आपके delomboked कोड पर javadoc चलाना है।
रोयल स्पिलकर

14
@ गैरीफ़ सच में? कैसे दस्तावेज़ीकरण के बारे में कि क्या मूल्य शून्य हो सकता है? या संख्यात्मक मान के लिए अनुमेय सीमा? या अनुमेय लंबाई और / या एक स्ट्रिंग मूल्य का प्रारूप? या क्या एक स्ट्रिंग मूल्य एक अंतिम उपयोगकर्ता को प्रस्तुत करने के लिए उपयुक्त है? या दस्तावेज यह कि वास्तव में संपत्ति का क्या मतलब है, जब इसका नाम संभवतः इसे पूरी तरह से समझा नहीं सकता है? ( JList.getLayoutOrientation और JList.setLayoutOrientation दिमाग में आते हैं।)
VGR

21
@ वीजीआर मैं सहमत हूं कि आप आम तौर पर क्या कह रहे हैं, लेकिन उस विशिष्ट मामले में बेहतर समाधान बेहतर नामकरण है, टिप्पणी नहीं। यानी getCreationDate, getDueDate। नामकरण ट्रंप की टिप्पणी जहां संभव हो।
गैरीफ

850

बस आज लोम्बोक का उपयोग शुरू कर दिया। अब तक मुझे यह पसंद है, लेकिन एक कमी जो मैंने नहीं देखी थी वह थी समर्थन को फिर से भरना।

यदि आपके पास एक वर्ग एनोटेट है @Data, तो यह क्षेत्र के नामों के आधार पर आपके लिए गेटर्स और सेटर्स उत्पन्न करेगा। यदि आप किसी अन्य क्लास में उन गेटर्स में से किसी एक का उपयोग करते हैं, तो तय करें कि फ़ील्ड खराब नाम पर है, यह उन गेटर्स और बसने वालों का उपयोग नहीं करेगा और पुराने नाम को नए नाम से बदल देगा।

मुझे लगता है कि यह एक IDE प्लग-इन के माध्यम से किया जाना चाहिए, और लोम्बोक के माध्यम से नहीं।

अद्यतन (जनवरी 22 '13)
3 महीने के लिए लोम्बोक का उपयोग करने के बाद, मैं अभी भी ज्यादातर परियोजनाओं के लिए इसकी सिफारिश करता हूं। हालाँकि, मैंने एक और कमी पाई है, जो ऊपर सूचीबद्ध सूची के समान है।

यदि आपके पास एक वर्ग है, तो कहें MyCompoundObject.javaकि 2 सदस्य हैं, दोनों ने एनोटेट किया @Delegate, कहते हैं myWidgetsऔर myGadgets, जब आप myCompoundObject.getThingies()किसी अन्य वर्ग से कॉल करते हैं , तो यह जानना असंभव है कि क्या यह प्रतिनिधि है Widgetया नहीं Gadgetक्योंकि आप अब आईडीई के भीतर स्रोत पर नहीं जा सकते।

एक्लिप्स "जनरेट डेलिगेट मेथड्स ..." का उपयोग करना आपको समान कार्यक्षमता प्रदान करता है, बस जल्दी है और सोर्स जंपिंग प्रदान करता है। नकारात्मक पक्ष यह है कि आपके स्रोत को बॉयलरप्लेट कोड के साथ बंद कर दिया जाता है जो महत्वपूर्ण सामानों पर ध्यान केंद्रित करता है।

अद्यतन 2 (फ़रवरी 26 '13)
5 महीने के बाद, हम अभी भी लोमबोक का उपयोग कर रहे हैं, लेकिन मुझे कुछ अन्य झुंझलाहट हैं। घोषित गेटटर और सेटर की कमी कई बार आपको परेशान कर सकती है जब आप खुद को नए कोड से परिचित कराने की कोशिश कर रहे हों।

उदाहरण के लिए, अगर मुझे कोई विधि दिखाई देती है, getDynamicCols()लेकिन मुझे नहीं पता कि यह किस बारे में है, तो मुझे इस पद्धति के उद्देश्य को निर्धारित करने के लिए कूदने के लिए कुछ अतिरिक्त बाधाएँ हैं। कुछ बाधाएं लोम्बोक हैं, कुछ लोम्बोक स्मार्ट प्लगइन की कमी हैं। बाधाओं में शामिल हैं:

  • JavaDocs की कमी। यदि मैं इस क्षेत्र में जावदॉक करता हूं, तो मुझे उम्मीद है कि लॉटर और सेटर लोनोक कंपार्टमेंट कदम के माध्यम से उस जवदोक को प्राप्त करेंगे।
  • जंप टू मेथड परिभाषा मुझे कूदता है क्लास के लिए, लेकिन संपत्ति नहीं जो उत्पन्न करने वाला। यह एक प्लगइन समस्या है।
  • स्पष्ट रूप से आप एक गेटर / सेटर में एक ब्रेकपॉइंट सेट करने में सक्षम नहीं हैं जब तक कि आप विधि उत्पन्न या कोड नहीं करते हैं।
  • नोट: यह संदर्भ खोज कोई समस्या नहीं है क्योंकि मैंने पहले सोचा था कि यह था। आपको एक परिप्रेक्ष्य का उपयोग करने की आवश्यकता है जो आउटलाइन दृश्य को सक्षम करता है। अधिकांश डेवलपर्स के लिए कोई समस्या नहीं है। मेरी समस्या यह थी कि मैं माइलिन का उपयोग कर रहा था जो मेरे Outlineविचार को फ़िल्टर कर रहा था, इसलिए मैंने तरीके नहीं देखे। संदर्भों की कमी। अगर मैं देखना चाहता हूं कि कॉलिंग किसे है getDynamicCols(args...), तो मुझे संदर्भ के लिए खोज करने में सक्षम होने के लिए सेटर को जेनरेट या कोड करना होगा।

अद्यतन 3 (मार्च 7 '13)
ग्रहण में चीजों के विभिन्न तरीकों का उपयोग करने के लिए सीखना मुझे लगता है। आप वास्तव में एक लोम्बोक उत्पन्न विधि पर एक सशर्त ब्रेकपॉइंट (बीपी) सेट कर सकते हैं। Outlineदृश्य का उपयोग करके , आप विधि को राइट-क्लिक कर सकते हैं Toggle Method Breakpoint। फिर जब आप बीपी से टकराते हैं, तो आप डिबगिंग Variablesदृश्य का उपयोग यह देखने के लिए कर सकते हैं कि उत्पन्न विधि को पैरामीटर (आमतौर पर फ़ील्ड नाम के समान) और अंत में, Breakpointsबीपी को राइट-क्लिक करने के लिए दृश्य का उपयोग करें और Breakpoint Properties...एक शर्त जोड़ने के लिए चुनें । अच्छा लगा।


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

अद्यतन 5 (जनवरी 17 '14) लोम्बोक
हमेशा ग्रूवी या कम से कम के साथ अच्छा नहीं खेलता है groovy-eclipse-compiler। आपको संकलक के अपने संस्करण को डाउनग्रेड करना पड़ सकता है। मावेन ग्रोवी और जावा + लोम्बोक

अद्यतन 6 (जून 26 '14)
चेतावनी का एक शब्द। लोम्बोक थोड़ा नशे की लत है और अगर आप एक ऐसी परियोजना पर काम करते हैं जहां आप किसी कारण से इसका उपयोग नहीं कर सकते हैं, तो यह आपके बाहर पेशाब को परेशान करेगा। आप बेहतर हो सकता है बस इसका इस्तेमाल कभी न करें।

अद्यतन 7 (जुलाई 23 '14)
यह एक दिलचस्प अपडेट का एक सा है क्योंकि यह सीधे ओम्को के बारे में पूछे गए लोम्बोक को अपनाने की सुरक्षा को संबोधित करता है ।

V1.14 के रूप में, @Delegateएनोटेशन को एक प्रायोगिक स्थिति में डिमोट किया गया है। विवरण उनकी साइट ( लोम्बोक डेलिगेट डॉक्स ) पर प्रलेखित हैं ।

बात यह है, यदि आप इस सुविधा का उपयोग कर रहे थे, तो आपके बैकआउट विकल्प सीमित हैं। मुझे इसके विकल्प दिखाई देते हैं:

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

जहां तक ​​मैं बता सकता हूं, डेलम्बोक में एनोटेशन के सबसेट को हटाने का विकल्प नहीं है ; यह सब या कम से कम एक फ़ाइल के संदर्भ के लिए कुछ भी नहीं है। मैंने Delombok झंडे के साथ इस सुविधा का अनुरोध करने के लिए एक टिकट खोला , लेकिन मैं निकट भविष्य में इसकी उम्मीद नहीं करूंगा।

अद्यतन 8 (अक्टूबर 20 '14)
यदि यह आपके लिए एक विकल्प है, तो ग्रोवी, लोंबोक के अधिकांश समान लाभ प्रदान करता है, साथ ही अन्य सुविधाओं के एक नाव लोड @Delegate भी शामिल है । यदि आपको लगता है कि आपके पास शक्तियों को विचार बेचने में एक कठिन समय होगा, तो यह देखने के लिए @CompileStaticया @TypeCheckedएनोटेशन पर एक नज़र डालें कि क्या यह आपके कारण की मदद कर सकता है। वास्तव में, ग्रूवी 2.0 रिलीज का प्राथमिक फोकस स्थिर सुरक्षा था

UPDATE 9 (1 सितंबर 15)
लोम्बोक को अभी भी सक्रिय रूप से बनाए रखा और बढ़ाया जा रहा है , जो गोद लेने के सुरक्षा स्तर के लिए बहुत अच्छा है। @Builder एनोटेशन मेरे पसंदीदा नई सुविधाओं में से एक है।

अद्यतन 10 (नवंबर 17 '15)
यह सीधे ओपी के सवाल से संबंधित नहीं लग सकता है, लेकिन साझा करने के लायक है। यदि आप अपने द्वारा लिखे गए बॉयलरप्लेट कोड की मात्रा को कम करने में मदद करने के लिए उपकरणों की तलाश कर रहे हैं, तो आप Google Auto - विशेष रूप से AutoVueue में भी देख सकते हैं । यदि आप उनके स्लाइड डेक को देखते हैं , तो समस्या के संभावित समाधान के रूप में लंबोक को हल करने की कोशिश कर रहे हैं। वे लोम्बोक के लिए जिस सूची को सूचीबद्ध करते हैं वह हैं:

  • सम्मिलित कोड अदृश्य है (आप इसे उत्पन्न करने के तरीकों को नहीं देख सकते हैं) [एड नोट - वास्तव में आप कर सकते हैं, लेकिन इसके लिए केवल एक डिकॉम्पिलेटर की आवश्यकता होती है]
  • कंपाइलर हैक गैर-मानक और नाजुक होते हैं
  • "हमारे विचार में, आपका कोड अब वास्तव में जावा नहीं है"

मुझे यकीन नहीं है कि मैं उनके मूल्यांकन से कितना सहमत हूं। और ऑटोवाल्यू की सहमति को देखते हुए जो स्लाइड्स में प्रलेखित हैं, मैं लोम्बोक (यदि ग्रूवी एक विकल्प नहीं है) के साथ चिपके रहेंगे।

अद्यतन 11 (फरवरी 8 '16)
मुझे पता चला कि स्प्रिंग रूओ के कुछ समान एनोटेशन हैं । मुझे यह जानकर थोड़ी हैरानी हुई कि रूही अभी भी एक चीज है और एनोटेशन के लिए प्रलेखन ढूंढना थोड़ा कठिन है। निष्कासन भी de-lombok जितना आसान नहीं दिखता है। लोम्बोक सुरक्षित विकल्प की तरह लगता है।

अद्यतन 12 (फ़रवरी 17 '16)
इस परियोजना के लिए लोम्बोक में लाने के लिए सुरक्षित होने के औचित्य के साथ आने की कोशिश करते हुए मैं वर्तमान में काम कर रहा हूं, मैंने पाया कि सोने का एक टुकड़ा v1.14- विन्यास प्रणाली के साथ जोड़ा गया था ! इसका मतलब है कि आप एक परियोजना को कुछ सुविधाओं को अस्वीकार करने की अनुमति देने के लिए कॉन्फ़िगर कर सकते हैं जो आपकी टीम असुरक्षित या अवांछनीय समझती है। बेहतर अभी तक, यह अलग-अलग सेटिंग्स के साथ निर्देशिका विशिष्ट कॉन्फ़िगरेशन भी बना सकता है। यह कमाल का है।

अद्यतन 13 (अक्टूबर 4 '16)
यदि इस तरह की बात आपके लिए मायने रखती है, तो ओलिवर गिएरेको लगा कि लोम्बोक को स्प्रिंग डेटा रेस्ट में जोड़ना सुरक्षित था ।

अद्यतन 14 (सितम्बर 26 '17)
जैसा कि ओप्स प्रश्न पर टिप्पणियों में @gavenkoa द्वारा बताया गया है , JDK9 संकलक समर्थन अभी तक उपलब्ध नहीं है (अंक # 985)। यह भी लगता है कि यह लोम्बोक टीम के लिए एक आसान तय नहीं है।

UPDATE 15 (26 मार्च 18)
लोम्बोक चेंगलॉग v1.16.20 के रूप में इंगित करता है " JDK1.9 पर लोमबेक का संकलन अब संभव है " भले ही # 985 अभी भी खुला है।

JDK9 को समायोजित करने के लिए परिवर्तन, हालांकि, कुछ टूटने वाले परिवर्तनों की आवश्यकता थी; सभी डिफ़ॉल्ट चूक में परिवर्तन के लिए अलग। यह थोड़ा सा है कि उन्होंने ब्रेकिंग परिवर्तन की शुरुआत की, लेकिन संस्करण ने केवल "इंक्रीमेंटल" संस्करण संख्या को टक्कर दी (v1.16.18 से v1.16.20 तक)। चूँकि यह पोस्ट सुरक्षा के बारे में थी, अगर आपके पास एक ऐसा yarn/npmबिल्ड सिस्टम था जो स्वचालित रूप से नवीनतम वृद्धिशील संस्करण में अपग्रेड हो जाता है, तो आप असभ्य जागृति के लिए हो सकते हैं।

अद्यतन 16 (जनवरी 9 '19)

ऐसा लगता है कि JDK9 मुद्दों को हल कर दिया गया है और Lombok JDK10 के साथ काम करता है, और यहां तक ​​कि JDK11 जहां तक ​​मैं बता सकता हूं।

एक बात जिस पर मैंने गौर किया, वह यह थी कि सुरक्षा पहलू से संबंधित था तथ्य यह है कि परिवर्तन लॉग v1.18.2 से v1.18.4 तक जा रहा है, दो वस्तुओं को सूचीबद्ध करता है BREAKING CHANGE? मुझे यकीन नहीं है कि एक सेमर "पैच" अपडेट में एक ब्रेकिंग परिवर्तन कैसे होता है। यदि आप किसी ऐसे उपकरण का उपयोग करते हैं जो ऑटो-अपडेट पैच संस्करणों का उपयोग करता है, तो यह एक समस्या हो सकती है।


49
धन्यवाद मुझे लगता है कि यह वह जानकारी थी जो ओपी वास्तव में दार्शनिक प्रतिक्रिया के विपरीत चाहता था।
चोस्तोरी

14
UPDATE 6बहुत कुछ लगता है जैसे स्काला :)
मौहिज़

5
@ मौहिज़ और ग्रूवी अगर मुझे कभी ऐसी जगह काम करना पड़े जहाँ मैं कम से कम परीक्षण के लिए ग्रूवी या स्काला का उपयोग न कर पाऊं, तो मैं शायद कम समय में छोड़ दूं।
स्नेक

8
मुझे वास्तव में समय शैली प्रतिक्रिया पर आपके अपडेट पसंद हैं। विशेष रूप से इस शैली की एक प्रश्न / प्रतिक्रिया के लिए यह वास्तव में मदद करता है।
MattG

4
ऐसा लगता है कि जावा 9 सपोर्ट अब उपलब्ध है। आप अपना जवाब अपडेट कर सकते हैं। stackoverflow.com/questions/41520511/…
leventunver

115

आगे बढ़ो और लोम्बोक का उपयोग करें, यदि आवश्यक हो तो आप अपने कोड के बाद "delombok" कर सकते हैं http://projectlombok.org/features/delombok.html


5
@fastcodejava जब आप "+1 फॉर x" कहते हैं, तो x को बिंदुओं में से एक होना चाहिए न कि एक और केवल एक बिंदु पर :)
केरेम बड्डूअन

7
इस विशेष स्थिति में, मैंने "+1 फॉर डेलम्बॉक" की व्याख्या "लॉन्ग लाइव डेलम्बोक" के रूप में की। मुझें यह पसंद है।
ज़ोल्टन

1
"डेलबॉम्बॉक के लिए +1" - विशेष रूप से सच है जब आप अपने ग्राहकों को प्रदान की जाने वाली परियोजनाओं में लम्बोक का उपयोग करना चाहते हैं। आप लुम्बोक के सभी फायदे ले सकते हैं और अपने ग्राहकों को लम्बोक निर्भरता के बिना एक साफ जार देखने दें।
fwonce

"ठीक है" सोचने वाले लोगों के लिए, मैं लोम्बोक को एक कोशिश दूंगा, और अगर मुझे यह पसंद नहीं है, तो मैं सिर्फ डेलम्बोक हूँ ": दो बार सोचें। डेलम्बोक चलाना एक दर्दनाक प्रक्रिया है। और परिणामी कोड काम करेगा जैसे कि यह लोम्बोक के साथ किया था ... लेकिन यह पूरी तरह गड़बड़ भी होगा।
एजेपेरेस

75

व्यक्तिगत रूप से (और इसलिए विषयगत रूप से) मैंने पाया है कि लोम्बोक का उपयोग आईडीई / हैशकोड और समान जैसे जटिल तरीकों के स्वयं के कार्यान्वयन की तुलना में मैं जो भी हासिल करने की कोशिश कर रहा हूं उसके बारे में अधिक स्पष्टता देता है।

उपयोग करते समय

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

किसी आईडीई / स्वयं के कार्यान्वयन की तुलना में इक्वाल्स और हैशकोड को सुसंगत रखना और किन क्षेत्रों का मूल्यांकन किया जाता है, इस पर नज़र रखना बहुत आसान है। यह विशेष रूप से सच है जब आप अभी भी नियमित रूप से फ़ील्ड जोड़ / निकाल रहे हैं।

वही @ToStringएनोटेशन और इसके मापदंडों के लिए जाता है जो स्पष्ट रूप से शामिल / बहिष्कृत फ़ील्ड, गेटर्स या फ़ील्ड एक्सेस और वाइडर के उपयोग या कॉल न करने के बारे में वांछित व्यवहार को स्पष्ट रूप से संवाद करते हैं super.toString()

और फिर ( @Getterया @Setter(AccessLevel.NONE)वैकल्पिक रूप से किसी भी विचलन विधियों को ओवरराइड करके) के साथ एक पूरी कक्षा की व्याख्या करके यह तुरंत स्पष्ट हो जाता है कि खेतों के लिए कौन से तरीके उपलब्ध होंगे।

लाभ और पर जाना ..

मेरे दिमाग में यह कोड को कम करने के बारे में नहीं है, बल्कि स्पष्ट रूप से यह बताने के बारे में है कि आप क्या हासिल करने की इच्छा रखते हैं, बजाय इसके कि इसे जावदोक या कार्यान्वयन से समझ सकें। कम किया हुआ कोड किसी भी विचलन विधि को लागू करने को आसान बनाता है।


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

25

लोम्बोक महान है, लेकिन ...

लोम्बोक एनोटेशन प्रोसेसिंग के नियमों को तोड़ता है, इसमें नई स्रोत फाइलें उत्पन्न नहीं होती हैं। इसका मतलब यह है कि अगर यह गेटर्स / सेटर या जो कुछ भी मौजूद है, उससे उम्मीद करते हैं कि इसे दूसरे एनोटेशन प्रोसेसर के साथ इस्तेमाल किया जा सकता है।

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

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


22

मैं लोम्बोक के बारे में कुछ राय पढ़ता हूं और वास्तव में मैं इसे कुछ परियोजनाओं में उपयोग कर रहा हूं।

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

मेरे इस तरह सोचने के कारण:

  • आईडीई प्लगइन निर्भरता । लोम्बोक के लिए आईडीई समर्थन प्लगइन्स के माध्यम से है। यहां तक ​​कि अधिकांश समय में अच्छा काम करते हुए, आप हमेशा आईडीई के भविष्य के रिलीज में बनाए रखने के लिए इस प्लग इन से एक बंधक होते हैं और यहां तक ​​कि भाषा संस्करण (जावा 10+ भाषा के विकास को गति देगा)। उदाहरण के लिए, मैंने Intellij IDEA 2017.3 से 2018.1 तक अपडेट करने की कोशिश की और मैं ऐसा नहीं कर सका क्योंकि वास्तविक lombok प्लगइन संस्करण पर कुछ समस्या थी और मुझे प्लगइन के अपडेट होने की प्रतीक्षा करने की आवश्यकता थी ... यह भी एक समस्या है यदि आप एक अधिक वैकल्पिक आईडीई का उपयोग करना चाहते हैं जिसमें कोई भी लोम्बोक प्लगइन समर्थन नहीं है।
  • 'Usages का पता लगाएं ’समस्या। । लोम्बोक का उपयोग करके आप उत्पन्न गेट्टर, सेटर, कंस्ट्रक्टर, बिल्डर विधियों और आदि को नहीं देखते हैं, इसलिए, यदि आप यह पता लगाने की योजना बना रहे हैं कि आपके आईडीई द्वारा आपके प्रोजेक्ट में इन विधियों का उपयोग कहां किया जा रहा है, तो आप इसे केवल देख नहीं सकते हैं उस वर्ग के लिए जो इस छुपी हुई विधियों का मालिक है।
  • इतना आसान है कि डेवलपर्स इनकैप्सुलेशन को तोड़ने की परवाह नहीं करते हैं । मुझे पता है कि यह वास्तव में लोम्बोक की समस्या नहीं है। लेकिन मैंने डेवलपर्स से एक बड़ी प्रवृत्ति को नियंत्रित करने के लिए देखा कि अब क्या तरीके दिखाई देने या नहीं होने की आवश्यकता है। इसलिए, कई बार वे सिर्फ @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorयह सोचकर नकल और पेस्ट कर रहे होते हैं कि कक्षा को वास्तव में उजागर करने की क्या विधियाँ हैं।
  • बिल्डर ऑबसेशन ©। मैंने इस नाम का आविष्कार किया (उतरो, मार्टिन फाउलर)। मज़ाक के अलावा, एक बिल्डर बनाना इतना आसान है कि यहां तक ​​कि जब एक वर्ग में केवल दो पैरामीटर होते हैं, तो डेवलपर्स @Builderकंस्ट्रक्टर या एक स्थिर कंस्ट्रक्टर विधि के बजाय उपयोग करना पसंद करते हैं । कभी-कभी वे लोमबोक बिल्डर के अंदर एक बिल्डर बनाने की कोशिश भी करते हैं, जैसे अजीब स्थिति पैदा करते हैं MyClass.builder().name("Name").build().create()
  • अवरोधन करते समय अवरोध । यदि आप उपयोग कर रहे हैं, उदाहरण के लिए, एक @AllArgsConstructorऔर निर्माणकर्ता पर एक और पैरामीटर जोड़ने की आवश्यकता है, तो IDE आपको इस अतिरिक्त पैरामीटर को सभी स्थानों (ज्यादातर, परीक्षण) में जोड़ने में मदद नहीं कर सकता है जो क्लास को इंस्टेंट कर रहे हैं।
  • लोम्बोक को ठोस तरीकों से मिलाते हुए । आप एक लेटर / सेटर / आदि बनाने के लिए सभी परिदृश्यों में लोम्बोक का उपयोग नहीं कर सकते हैं। तो, आप अपने कोड में मिश्रित इन दोनों दृष्टिकोणों को देखेंगे। आपको कुछ समय बाद इसकी आदत हो जाती है, लेकिन भाषा पर हैक जैसा महसूस होता है।

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


8
मैं कहूंगा कि कोटलिन के लिए जाऊं या सादे जावा में रहूं। आप जावा कोड टाइप न करके आप जितना समय बचाते हैं, उससे अधिक समय आप लोम्बोक के मुद्दों पर लगा सकते हैं।
jediz

1
जो कोई केवल क्रिया के कारण जावा से नफरत करता है, वह अपने कोड को कम क्रिया नहीं बनाने के लिए उसकी गलती है ...
निकोलस

17

लंबे समय तक रखरखाव के जोखिम भी होते हैं। सबसे पहले, मैं, जैसे इसके डेवलपर्स से कुछ जवाब कैसे लंबोक वास्तव में काम करता है के बारे में पढ़ने की सलाह देते चाहते हैं यहाँ

आधिकारिक साइट में डाउनसाइड्स की एक सूची भी शामिल है , जिसमें रेनियर ज़्विट्स्लरलॉट का यह उद्धरण शामिल है:

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

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

यदि आप ऐसा कर सकते हैं जो lombok मानक API के साथ करता है, तो मैंने इसे इस तरह से किया होगा, लेकिन आप नहीं कर सकते। फिर भी, इसके मूल्य के लिए, मैंने java 1.6 पर चलने वाले v3.5 ग्रहण के लिए ग्रहण प्लगइन विकसित किया है, और बिना किसी परिवर्तन के इसने v3.4 पर काम किया जो java 1.5 पर भी चल रहा है, इसलिए यह पूरी तरह से नाजुक नहीं है।

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


8
ठीक है, अगर आप लोम्बोक का उपयोग नहीं कर सकते हैं, तो बस डेलम्बोक चलाएं और इसके बिना विकास जारी रखें।
vladich

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

15

मुझे पता है कि मुझे देर हो गई है, लेकिन मैं प्रलोभन का विरोध नहीं कर सकता: लोम्बोक को पसंद करने वाले किसी भी व्यक्ति को स्काला पर एक नज़र रखना चाहिए। कई अच्छे विचार जो आपको लोम्बोक में मिलते हैं, वे स्काला भाषा का हिस्सा हैं।

आपके प्रश्न पर: लोकाला को स्कैला की तुलना में अपने डेवलपर्स को प्राप्त करना निश्चित रूप से आसान है। इसे आज़माएँ और अगर उन्हें यह पसंद है, तो स्काला आज़माएँ।

बस एक अस्वीकरण के रूप में: मुझे जावा भी पसंद है!


मुझे स्काला और लोम्बोक पसंद है, लेकिन मैं यह नहीं देख सकता कि आप किन विचारों के बारे में बात कर रहे हैं। \ @SneakyThrows, \ @ डेटा, ...?
sinuhepop

2
@sinuhepop जनरेटर्स और सेटर केस क्लास की तरह दिखते हैं। अपरिवर्तनीय-सुविधा स्कैला अंतर्निहित है और अपने स्वयं के तरीकों के बारे में एपीआई को समृद्ध करना स्कैला सुविधा में भी बनाया गया है।
sorencito


15

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


27
आप सिर दर्द पर विस्तृत कर सकते हैं?
केविन वेलकर

2
ग्रहण के लिए सेटअप बेहद सीधा है। बस "जावा -रज lombok.jar"।

14
मुझे लगता है कि एक नया डेवलपर स्थापित करने का सबसे कठिन हिस्सा यह महसूस कर रहा है कि आपको लोम्बोक की स्थापना करने की आवश्यकता है। "लोम्बोक सेटअप नहीं किया गया है" या ऐसा कुछ भी कहने का कोई संदेश नहीं है। इसके बजाय आपको अजीब संदेश मिलते हैं जैसे "setFoo" परिभाषित नहीं है। यदि लोम्बोक शिक्षा आपके नए डेवलपर ऑन-बोर्ड प्रशिक्षण प्रक्रिया का हिस्सा नहीं है, तो बड़ी उलझन होगी।
स्नेक

@Snekse। मुझे ठीक से पता नहीं है कि कौन सा lombok प्लगइन संस्करण इंटेलीज आइडिया नोटिफिकेशन और सुझाव पेश करता है (एक लाल संदेश और सुझाव पॉप अप में एरर लॉग इन करता है ताकि उपयोगकर्ता एनोटेशन को सक्षम कर सके और यहां तक ​​कि कॉन्फ़िगरेशन सेक्शन को लिंक भी प्रदान कर सके), लेकिन Idea.3.3 और 0.13.16 प्लगइन संस्करण में यह उपयोगी समर्थन शामिल है।
जोंटिक

2
लोमबोक विचार प्लगइन (मैं संस्करण 0.13.16 का उपयोग करता हूं) हाल ही में उपयोगकर्ता को सूचित करने के लिए समर्थन का परिचय देता है कि एनोटेशन प्रोसेसर कॉन्फ़िगर नहीं किया गया था और यह भी सक्षम करने के लिए कॉन्फ़िगरेशन सेटिंग्स अनुभाग के लिए एक लिंक प्रदान करता है। कृपया स्क्रीनशॉट को देखें Postimg.org/image/5tm2zzvkh
jtonic

11

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

  • जहां तक ​​आरओआई है, यह एकीकृत करने के लिए एक स्नैप है, और इसके मूल रूप में कोड परिवर्तन की आवश्यकता नहीं है। (सिर्फ अपनी कक्षा में एक एकल एनोटेशन जोड़ना)

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


10

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

  1. यह विकल्प वाक्य रचना के एक अविवेक परत (पढ़ के साथ अपने कोड को प्रदूषित करता है @Getter, @Setterआदि एनोटेशन)। जावा के लिए एक वैकल्पिक वाक्यविन्यास सीखने के बजाय, मैं किसी अन्य भाषा में स्विच करूंगा जो मूल रूप से लोम्बोक को वाक्य रचना की तरह प्रदान करती है।
  2. लोम्बोक को आपके कोड के साथ काम करने के लिए एक लोम्बोक समर्थित आईडीई के उपयोग की आवश्यकता होती है। यह निर्भरता किसी भी गैर-तुच्छ परियोजना के लिए काफी जोखिम का परिचय देती है। क्या ओपन सोर्स लोम्बोक प्रोजेक्ट के पास पर्याप्त संसाधन हैं जो जावा आईडीई की उपलब्ध विस्तृत श्रृंखला के विभिन्न संस्करणों के लिए समर्थन प्रदान करते हैं?
  3. क्या ओपन सोर्स लोम्बोक परियोजना के पास जावा के नए संस्करणों के लिए समर्थन प्रदान करने के लिए पर्याप्त संसाधन हैं जो भविष्य में आने वाले हैं?
  4. मुझे यह भी घबराहट होती है कि लोम्बोक व्यापक रूप से उपयोग किए गए फ्रेमवर्क / लाइब्रेरी (जैसे स्प्रिंग, हाइबरनेट, जैक्सन, जुनिट, मॉकिटो) के साथ संगतता के मुद्दों को पेश कर सकता है जो रनटाइम पर आपके बाइट कोड के साथ काम करते हैं।

सभी में मैं लोम्बोक के साथ अपने जावा को "मसाला" करना पसंद नहीं करूंगा।


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

10

लेम्बोक का उपयोग करना चाहते थे, @ToStringलेकिन जल्द ही इंटेलीज आईडीईए में परियोजना पुनर्निर्माण पर यादृच्छिक संकलन त्रुटियों का सामना करना पड़ा। वृद्धिशील संकलन सफलता के साथ पूरा होने से पहले कई बार संकलित करना पड़ा।

दोनों को 1.12.2 और 0.9.3 दोनों को Intellij IDEA 12.1.6 और 13.0 के साथ jdk 1.6.0_39 और 1.6.0_45 के तहत किसी भी lombok प्लगइन की कोशिश की।

मैन्युअल तरीके से उत्पन्न तरीकों को कॉपी करना और बेहतर समय तक लोबोक को पकड़ में रखना था।

अपडेट करें

समस्या समांतर संकलन सक्षम के साथ ही होती है।

एक मुद्दा दायर: https://github.com/rzwitserloot/lombok/issues/648

अपडेट करें

mplushnikov ने 30 जनवरी 2016 को टिप्पणी की:

Intellij के नए संस्करण में अब ऐसे मुद्दे नहीं हैं। मुझे लगता है कि इसे यहां बंद किया जा सकता है।

अपडेट करें

यदि संभव हो तो मैं जावा + लोम्बोक से कोटलिन जाने की सलाह दूंगा । जैसा कि यह जमीन से सभी जावा मुद्दों को हल कर चुका है जो लोम्बोक के आसपास काम करने की कोशिश करता है।


6

मुझे लोम्बोक और जैक्सन CSV के साथ एक समस्या का सामना करना पड़ा है , जब मैंने अपनी वस्तु (जावा बीन) को एक CSV फ़ाइल में स्तंभित किया, जहां कॉलम डुप्लिकेट किए गए थे, तब मैंने लोम्बोक के @Data एनोटेशन को हटा दिया और मार्शलाइज़िंग ने ठीक काम किया।


2

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


तो आप JavaBeans को एनोटेट करने की क्या सलाह देते हैं?
इगोरगानापोलस्की 23

लोमबोक टीम ने अपना कोड अपडेट कर दिया है। फिर भी, मुझे इसके तैयार होने से पहले कई महीनों तक इंतजार करना होगा
हारुन

0

मैंने अभी तक लोमबोक का उपयोग करने की कोशिश नहीं की है - यह मेरी सूची में था / है, लेकिन ऐसा लगता है जैसे जावा 8 ने इसके लिए महत्वपूर्ण समस्याएं पैदा की हैं, और उपचारात्मक कार्य अभी भी एक सप्ताह पहले की तरह चल रहा था। उसके लिए मेरा स्रोत https://code.google.com/p/projectlombok/issues/detail?id=451 है


सिर्फ रिकॉर्ड के लिए, उस मुद्दे को github.com/rzwitserloot/lombok/issues/524
seanf

1
मुझे जावा 8
एलेक्सी

मैं अभी महीनों से lombok के साथ काम कर रहा था और यह Java 8 के साथ अच्छी तरह से काम करता है। मैं जिस प्रोजेक्ट पर काम कर रहा हूं वह पहले से ही सालों से lombok का उपयोग कर रहा है और अब तक कोई समस्या नहीं आई है।
कीवेनलोलो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.