هل من الآمن استخدام Project Lombok؟ [مغلق

Question

في حال كنت لا تعرف مشروع لومبوك يساعد في بعض إزعاج جافا مع أشياء مثل توليد getters والمستقبين مع التعليقات التوضيحية وحتى جافابان بسيط مثل جيل مع data. يمكن أن يساعدني ذلك حقًا ، خاصة في 50 كائنًا مختلفًا للأحداث حيث يكون لديك ما يصل إلى 7 حقول مختلفة تحتاج إلى بناء وإخفاء مع getters. يمكنني إزالة ما يقرب من ألف سطر من التعليمات البرمجية مع هذا.

ومع ذلك ، أشعر بالقلق من أنه على المدى الطويل ، سيكون قرارًا مؤسفًا. سوف تندلع الفلامير في ##Java Freenode القناة عندما أذكرها ، فإن توفير قصاصات الرمز سوف يخلط بين المساعدين المحتملين ، سوف يشتكي الناس من فقدان جافادوك, ، وقد يزيل اللاعبين في المستقبل كل شيء على أي حال. سأستمتع حقًا بالإيجابية ، لكنني قلق بشأن السلبية.

لذلك: هل من الآمن استخدام لومبوك على أي مشروع ، صغير أو كبير؟ هل الآثار الإيجابية تستحق السلبيات؟

Answer 1

يبدو أنك قررت بالفعل أن Project Lombok يمنحك مزايا فنية كبيرة لمشروعك الجديد المقترح. (لأكون واضحًا منذ البداية ، ليس لدي وجهات نظر معينة حول Project Lombok ، بطريقة أو بأخرى.)

قبل استخدام Project Lombok (أو أي تقنية أخرى لتغيير اللعبة) في بعض المشاريع (المصدر المفتوح أو غيرها من الحكمة) ، تحتاج إلى التأكد من أن أصحاب المصلحة في المشروع يوافقون على ذلك. ويشمل ذلك المطورين ، وأي مستخدمين مهمين (مثل الرعاة الرسميين أو غير الرسميين).

ذكرت هذه القضايا المحتملة:

سوف تندلع Flamewars في قناة ## Java Freenode عندما أذكرها ،

سهل. تجاهل / لا تشارك في Flamewars ، أو ببساطة الامتناع عن ذكر Lombok.

سيؤدي توفير قصاصات الرمز إلى إرباك المساعدين المحتملين ،

إذا كانت استراتيجية المشروع هي استخدام Lombok ، فستحتاج المساعدون المحتملين إلى التعود عليه.

سوف يشكو الناس من فقدان جافادوك ،

هذه هي مشكلتهم. لا أحد في عقلهم الصحيح يحاول تطبيق قواعد / الوثائق المصدر المصدر بشكل صارم على برنامج المصدر المفتوح من طرف ثالث. يجب أن يكون فريق المشروع مجانيًا في تعيين معايير التعليمات / الوثائق المصدر المصدر المناسبة للتكنولوجيا المستخدمة.

(متابعة - يدرك مطورو Lombok أن عدم توليد تعليقات Javadoc على أساليب Getter و Setter تم تصنيعها مشكلة. إذا كانت هذه مشكلة كبيرة لمشروعك (مشروعك) ، فإن أحد البديل هو إنشاء تصحيح لومبوك وإرساله لمعالجة هذا.)

وقد يزيل اللاعبين في المستقبل كل شيء على أي حال.

هذا ليس على! إذا كانت استراتيجية المشروع المتفق عليها هي استخدام Lombok ، فيجب أن يتم سحب الرئاسة الذين لا مبرر لهم عن القانون ، وإذا لزم الأمر سحب حقوق التزامهم.

بالطبع ، يفترض هذا أنك حصلت على مشاركة من أصحاب المصلحة ... بما في ذلك المطورين. ويفترض أنك مستعد للمناقشة قضيتك ، والتعامل مع الأصوات المعارضة التي لا مفر منها بشكل مناسب.

Answer 2

بدأت للتو في استخدام لومبوك اليوم. حتى الآن يعجبني ، لكن عيبًا واحدًا لم أره هو دعم إعادة تمهيد.

إذا كان لديك فصل شرح مع @Data, ، سيقوم بإنشاء Getters و Petters لك بناءً على أسماء الحقول. إذا كنت تستخدم واحدة من هؤلاء getters في فصل آخر ، فحدد أن الحقل سيئ تسمية بشكل سيئ ، فلن يجد استخدامات هؤلاء المتجولين والمستقلين واستبدال الاسم القديم بالاسم الجديد.

أتصور أن هذا يجب أن يتم عبر مكون إضافي IDE وليس عبر Lombok.

تحديث (22 يناير 13)
بعد استخدام Lombok لمدة 3 أشهر ، ما زلت أوصي به لمعظم المشاريع. ومع ذلك ، فقد وجدت عيبًا آخر مشابهًا للذات المذكورة أعلاه.

إذا كان لديك فصل ، قل MyCompoundObject.java هذا لديه عضوين ، كلاهما مشروح مع @Delegate, ، قل myWidgets و myGadgets, ، عندما تتصل myCompoundObject.getThingies() من فئة أخرى ، من المستحيل معرفة ما إذا كان يفوض Widget أو Gadget لأنه لم يعد بإمكانك القفز إلى المصدر داخل IDE.

إن استخدام Eclipse "إنشاء أساليب مندوب ..." يوفر لك نفس الوظيفة ، وهو سريع تمامًا ويوفر القفز المصدر. الجانب السلبي هو أنه يعرض مصدرك برمز Boilerplate الذي يركز على الأشياء المهمة.

تحديث 2 (26 فبراير 13)
بعد 5 أشهر ، ما زلنا نستخدم Lombok ، لكن لدي بعض الإزعاج الآخر. يمكن أن يكون الافتقار إلى getter & setter معلنًا مزعجًا في بعض الأحيان عندما تحاول التعرف على رمز جديد.

على سبيل المثال ، إذا رأيت طريقة تسمى getDynamicCols() لكنني لا أعرف ما الذي يدور حوله ، لدي بعض العقبات الإضافية للقفز لتحديد الغرض من هذه الطريقة. بعض العقبات هي لومبوك ، بعضها هو عدم وجود مكون إضافي لومبوك الذكي. تشمل العقبات:

• عدم وجود Javadocs. إذا كنت Javadoc في الحقل ، آمل أن يرث Getter و Setter أن Javadoc من خلال خطوة تجميع Lombok.
• القفز إلى تعريف الطريقة يقفزني إلى الفصل ، ولكن ليس الخاصية التي ولدت Getter. هذه مشكلة البرنامج المساعد.
• من الواضح أنك غير قادر على تعيين نقطة توقف في getter/setter إلا إذا قمت بإنشاء أو ترميز الطريقة.
• ملاحظة: هذا البحث المرجعي ليس مشكلة كما اعتقدت أولاً. تحتاج إلى استخدام منظور يتيح عرض الخطوط التفصيلية. ليست مشكلة لمعظم المطورين. كانت مشكلتي هي أنني أستخدم Mylly الذي كان يقوم بتصفية بلدي Outline عرض ، لذلك لم أر الطرق. عدم وجود مراجع البحث. إذا أردت أن أرى من يتصل getDynamicCols(args...), ، يجب أن أقوم بإنشاء أو رمز Setter لتكون قادرًا على البحث عن المراجع.

تحديث 3 (7 مارس 13)
تعلم استخدام الطرق المختلفة لعمل الأشياء في الكسوف أعتقد. يمكنك بالفعل تعيين نقطة توقف مشروطة (BP) على طريقة لومبوك التي تم إنشاؤها. باستخدام Outline عرض ، يمكنك النقر بزر الماوس الأيمن على الطريقة Toggle Method Breakpoint. ثم عندما تضغط على BP ، يمكنك استخدام تصحيح الأخطاء Variables عرض لمعرفة الطريقة التي تم إنشاؤها المسمى المعلمات (عادة ما تكون نفس اسم الحقل) وأخيراً ، استخدم Breakpoints عرض للنقر بزر الماوس الأيمن على BP وحدد Breakpoint Properties... لإضافة حالة. لطيف - جيد.

تحديث 4 (16 أغسطس 13)
لا يحب NetBeans ذلك عند تحديث تبعيات Lombok في POM Maven. لا يزال المشروع يجمع ، ولكن يتم وضع علامة على الملفات للحصول على أخطاء في التجميع لأنه لا يمكن رؤية الطرق التي يقوم بها لومبوك. مسح ذاكرة التخزين المؤقت NetBeans يحل المشكلة. لست متأكدًا مما إذا كان هناك خيار "مشروع نظيف" كما هو الحال في Eclipse. قضية بسيطة ، لكنها أرادت أن تجعلها معروفة.

تحديث 5 (17 يناير 14)
لا يلعب Lombok دائمًا لطيفًا مع Groovy ، أو على الأقل groovy-eclipse-compiler. قد تضطر إلى تخفيض نسخك من المترجم.Maven Groovy و Java + Lombok

تحديث 6 (26 يونيو 14)
كلمة للتحذير. إن Lombok تسبب الإدمان قليلاً وإذا كنت تعمل في مشروع لا يمكنك استخدامه لسبب ما ، فسوف يزعجك. قد تكون أفضل حالًا فقط لا تستخدمه على الإطلاق.

تحديث 7 (23 يوليو 14)
هذا تحديث مثير للاهتمام لأنه يعالج مباشرة سلامة من تبني لومبوك التي سألها OP عنها.

اعتبارا من الإصدار 1.14 ، @Delegate تم تخفيض رحلات التعليقات التوضيحية إلى حالة تجريبية. تم توثيق التفاصيل على موقعهم (مستندات لومبوك مندوب).

الشيء ، إذا كنت تستخدم هذه الميزة ، فإن خياراتك المتراكمة محدودة. أرى الخيارات على النحو التالي:

• إزالة يدويا @Delegate التعليقات التوضيحية وإنشاء/رمز اليد رمز المندوب. هذا أصعب قليلاً إذا كنت تستخدم سمات ضمن التعليقات التوضيحية.
• Delombok الملفات التي لديها @Delegate التعليق التوضيحي وربما يضيف مرة أخرى في التعليقات التوضيحية التي تريدها.
• لا تقم أبدًا بتحديث Lombok أو الحفاظ على شوكة (أو العيش مع استخدام ميزات تجريبية).
• Delombok مشروعك بالكامل وتوقف عن استخدام Lombok.

بقدر ما أستطيع أن أقول ، ليس لدى Delombok خيار لإزالة مجموعة فرعية من التعليقات التوضيحية; ؛ كل شيء أو لا شيء على الأقل لسياق ملف واحد. أنا فتحت تذكرة لطلب هذه الميزة مع أعلام Delombok ، لكنني لا أتوقع ذلك في المستقبل القريب.

تحديث 8 (20 أكتوبر 14)
إذا كان خيارًا لك ، فإن Groovy يوفر معظم فوائد Lombok نفسها ، بالإضافة إلى حمولة قارب من الميزات الأخرى ، بما في ذلك @مندوب. إذا كنت تعتقد أنك ستواجه صعوبة في بيع الفكرة إلى القوى التي تكون ، ألق نظرة على @CompileStatic أو @TypeChecked التعليق التوضيحي لمعرفة ما إذا كان ذلك يمكن أن يساعد قضيتك. في الواقع، كان التركيز الأساسي لإصدار Groovy 2.0 هو السلامة الثابتة.

تحديث 9 (1 سبتمبر 15)
لوموك لا يزال يجري تم الحفاظ عليها وتعزيزها بنشاط, الذي يبشر بالخير إلى مستوى سلامة التبني. ال builder التعليقات التوضيحية هي واحدة من ميزاتي الجديدة المفضلة.

تحديث 10 (17 نوفمبر 15)
قد لا يبدو هذا مرتبطًا بشكل مباشر بسؤال البروتوكول الاختياري ، ولكنه يستحق المشاركة. إذا كنت تبحث عن أدوات لمساعدتك على تقليل كمية رمز Boilerplate الذي تكتبه ، فيمكنك أيضًا مراجعة Google Auto - خاصه ACTOVALUE. إذا نظرت إلى سطح الشريحة, ، قائمة Lombok كحل ممكن للمشكلة التي يحاولون حلها. سلبيات قائمة لومبوك هي:

• الرمز المدرج غير مرئي (لا يمكنك "رؤية" الطرق التي ينشئها) [ED ملاحظة - في الواقع يمكنك ذلك ، ولكنه يتطلب فقط decompiler
• الاختراقات المترجم غير قياسي وهشة
• "في وجهة نظرنا ، لم يعد الرمز الخاص بك Java حقًا"

لست متأكدًا من مدى موافقتي على تقييمهم. وبالنظر إلى سلبيات Actovalue التي تم توثيقها في الشرائح ، سألتزم بـ Lombok (إذا لم يكن Groovy خيارًا).

تحديث 11 (8 فبراير 16)
اكتشفت الربيع رو لديه بعض تعليقات توضيحية مماثلة. لقد فوجئت قليلاً بمعرفة أن رو لا يزال شيئًا وإيجاد وثائق للتعليقات التوضيحية أمر صعب بعض الشيء. لا تبدو الإزالة أيضًا سهلة مثل De-Lombok. لومبوك يبدو وكأنه الخيار الأكثر أمانًا.

تحديث 12 (17 فبراير 16)
أثناء محاولة التوصل إلى مبررات لسبب آمنة لجلب لومبوك للمشروع الذي أعمل عليه حاليًا ، وجدت قطعة من الذهب تمت إضافتها معها v1.14 - ال نظام التكوين! هذا يعني أنه يمكنك تكوين مشروع لتوضيح بعض الميزات التي يراها فريقك غير آمن أو غير مرغوب فيه. والأفضل من ذلك ، أنه يمكن أيضًا إنشاء تكوين محدد للدليل مع إعدادات مختلفة. هذا رائع.

تحديث 13 (4 أكتوبر 16)
إذا كان هذا النوع من الأشياء يهم لك ، أوليفر جيركي شعرت أنها آمنة أضف لومبوك إلى راحة الربيع.

تحديث 14 (26 سبتمبر 17)
كما أشار من قبل gavenkoa في التعليقات على سؤال OPS ، دعم برنامج التحويل البرمجي JDK9 غير متاح بعد (العدد رقم 985). يبدو أيضًا أنه لن يكون حلًا سهلاً لفريق Lombok للالتفاف.

تحديث 15 (26 مارس 18)
يشير Lombok Changelog إلى V1.16.20 "أصبح تجميع Lombok على 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! لست متأكدًا من كيفية حدوث تغيير في تحديث "تصحيح" Semver. يمكن أن تكون مشكلة إذا كنت تستخدم أداة تصحيح تحديث تلقائي.

Answer 3

المضي قدمًا واستخدم Lombok ، يمكنك إذا لزم الأمر "Delombok" رمزك بعد ذلك http://projectlombok.org/features/delombok.html

Answer 4

شخصياً (وبالتالي ذاتي) وجدت أن استخدام Lombok يجعل الكود الخاص بي أكثر تعبيرًا حول ما أحاول تحقيقه عند مقارنته بتطبيقات IDE/الخاصة بالطرق المعقدة مثل Hashcode & Equals.

عند استخدام

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

من الأسهل بكثير الحفاظ على متساوٍ وربط الحشائش وتتبع الحقول التي يتم تقييمها ، أكثر من أي تطبيق IDE/OWN. هذا صحيح بشكل خاص عندما لا تزال تضيف / إزالة الحقول بانتظام.

الشيء نفسه ينطبق على @ToString التعليقات التوضيحية ومعلماتها التي توصل بوضوح إلى السلوك المطلوب فيما يتعلق بالحقول المشمولة / المستبعدة ، أو استخدام getters أو الوصول الميداني واليثر أو عدم الاتصال super.toString().

ومرة أخرى عن طريق شرح فصل كامل مع @Getter أو @Setter(AccessLevel.NONE) (وتجاوز أي طرق متباينة اختياريًا) ، من الواضح على الفور الطرق المتاحة للحقول.

الفوائد تستمر وتواصل ..

في رأيي ، لا يتعلق الأمر بتقليل التعليمات البرمجية ، ولكن حول توصيل ما تريد تحقيقه بوضوح ، بدلاً من الاضطرار إلى اكتشافه من Javadoc أو التطبيقات. إن الكود المخفض يجعل من السهل تحديد أي تطبيقات ذات طريقة متباينة.

Answer 5

لومبوك رائع ، لكن ...

يكسر Lombok قواعد معالجة التعليقات التوضيحية ، من حيث أنه لا يولد ملفات مصدر جديدة. هذا يعني أنه لا يمكن استخدامه مع معالجات التعليقات التوضيحية الأخرى إذا كانوا يتوقعون getters/setters أو أي شيء آخر.

تعمل معالجة التعليقات التوضيحية في سلسلة من الجولات. في كل جولة ، يحصل كل واحد على منعطف للتشغيل. إذا تم العثور على أي ملفات Java جديدة بعد اكتمال الجولة ، تبدأ جولة أخرى. وبهذه الطريقة ، لا يهم ترتيب معالجات التعليقات التوضيحية إذا كانت لا تنشئ سوى ملفات جديدة. نظرًا لأن Lombok لا يقوم بإنشاء أي ملفات جديدة ، فلا يتم بدء أي جولات جديدة ، لذا فإن بعض AP تعتمد على رمز Lombok لا يتم تشغيله كما هو متوقع. كان هذا مصدرًا كبيرًا للألم بالنسبة لي أثناء استخدام MapStruct ، و Delombok-ing ليس خيارًا مفيدًا لأنه يدمر أرقام الخط في السجلات.

لقد اخترقت في النهاية برنامج نصي بناء للعمل مع كل من Lombok و MapTruct. لكني أريد إسقاط لومبوك بسبب مدى الاختراق - في هذا المشروع على الأقل. أستخدم لومبوك طوال الوقت في أشياء أخرى.

Answer 6

هناك مخاطر الصيانة طويلة الأجل كذلك. أولاً ، أوصي بالقراءة حول كيفية عمل لومبوك فعليًا ، على سبيل المثال بعض الإجابات من مطوريها هنا.

يحتوي الموقع الرسمي أيضًا على ملف قائمة الجوانب السلبية, ، بما في ذلك هذا الاقتباس من Reinier Zwitserloot:

إنه اختراق تام. باستخدام واجهة برمجة التطبيقات غير العامة. إن الصب المفترض (مع العلم أن معالج التعليق التوضيحي الذي يعمل في Javac سيحصل على مثال على JavacannotationProcessor ، وهو التنفيذ الداخلي للشرح التعليقات (واجهة) ، والتي تحدث أن لديها بضعة طرق إضافية تستخدم للوصول إلى AST Live) .

في Eclipse ، يمكن القول إنه أسوأ (وأكثر قوة) - يتم استخدام عميل Java لإضفاء حقن الكود في فئة Eclipse Grammar و Parser ، والتي هي بالطبع API غير الحكومية تمامًا وذات حدود خارجية تمامًا.

إذا تمكنت من فعل ما يفعله Lombok باستخدام API القياسي ، لكنت سأفعل ذلك بهذه الطريقة ، لكن لا يمكنك ذلك. ومع ذلك ، على ما قيمته ، قمت بتطوير المكون الإضافي Eclipse لـ Eclipse v3.5 الذي يعمل على Java 1.6 ، وبدون إجراء أي تغييرات ، عملت على Eclipse v3.4 تشغيل على Java 1.5 أيضًا ، لذلك ليس هشًا تمامًا.

كملخص ، على الرغم من أن Lombok قد يوفر لك بعض وقت التطوير ، إذا كان هناك تحديث Javac غير متوافق غير متوافق (مثل التخفيف من الضعف) قد يعلقك Lombok على إصدار قديم من Java بينما يتدافع المطورون لتحديث استخدامهم لهؤلاء واجهات برمجة التطبيقات الداخلية. ما إذا كان هذا خطرًا خطيرًا يعتمد بشكل واضح على المشروع.

Answer 7

قرأت بعض الآراء حول لومبوك وأنا في الواقع أستخدمها في بعض المشاريع.

حسنًا ، في أول اتصال مع لومبوك ، كان لدي انطباع سيء. بعد بضعة أسابيع ، بدأت أحب ذلك. ولكن بعد بضعة أشهر ، اكتشفت الكثير من المشاكل الصغيرة التي تستخدمها. لذلك ، انطباعي النهائي عن لومبوك ليس إيجابيًا.

أسبابي للتفكير بهذه الطريقة:

• IDE Plugin التبعية. دعم IDE لـ Lombok هو من خلال الإضافات. حتى العمل الجيد في معظم الوقت ، فأنت دائمًا رهينة من هذه المكونات الإضافية التي سيتم الحفاظ عليها في الإصدارات المستقبلية من IDES و حتى نسخة اللغة (سوف يسرع Java 10+ تطور اللغة). على سبيل المثال ، حاولت التحديث من Intellij IDE 2017.3 إلى 2018.1 ولم أستطع فعل ذلك لأن هناك بعض المشكلات في إصدار Lombok Plugin الفعلي وأحتاج إلى انتظار التحديث المكون الإضافي ... هذه مشكلة أيضًا إذا كنت مشكلة إذا كنت ترغب في استخدام IDE البديل الذي ليس لديه أي دعم إضافي لومبوك.
• "العثور على مشكلة".. باستخدام Lombok ، لا ترى getter ، setter ، مُنشئ ، أساليب البناء وما إلى ذلك تبحث عن الفصل الذي يمتلك هذه الأساليب الخفية.
• من السهل جدًا ألا يهتم المطورون بكسر التغليف. أعلم أنها ليست مشكلة من لومبوك. لكنني رأيت ميلًا أكبر للمطورين لم يعد يتحكم في الأساليب التي يجب أن تكون مرئية أم لا. لذلك ، في كثير من الأحيان يقومون بالنسخ واللصق فقط @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor التعليقات التوضيحية دون التفكير في الأساليب التي يحتاجها الفصل حقًا إلى الكشف عنها.
• باني أوص ©. اخترعت هذا الاسم (توقف ، مارتن فاولر). النكات بصرف النظر ، من السهل جدًا إنشاء المنشئ لدرجة أنه حتى عندما يكون لدى الفئة معلمتين فقط يفضل المطورون استخدامه @Builder بدلا من مُنشئ أو طريقة مُنشأة ثابتة. في بعض الأحيان يحاولون إنشاء منشئ داخل باني لومبوك ، ويخلقون مواقف غريبة مثل MyClass.builder().name("Name").build().create().
• الحواجز عند إعادة البناء. إذا كنت تستخدم ، على سبيل المثال ، أ @AllArgsConstructor وتحتاج إلى إضافة معلمة أخرى على المُنشئ ، لا يمكن لـ IDE مساعدتك في إضافة هذه المعلمة الإضافية في جميع الأماكن (في الغالب ، الاختبارات) التي تقوم بتسهيل الفصل.
• امزج لومبوك مع طرق ملموسة. لا يمكنك استخدام Lombok في جميع السيناريوهات لإنشاء getter/setter/etc. لذلك ، سترى هذين النهجين مختلطين في الكود الخاص بك. تعتاد على هذا بعد بعض الوقت ، ولكنك تشعر وكأنها اختراق للغة.

كما قال إجابة أخرى ، إذا كنت غاضبًا من فعل Java واستخدم Lombok للتعامل معه ، فحاول Kotlin.

Answer 8

أعلم أنني متأخر ، لكن لا يمكنني مقاومة الإغراء: يجب على أي شخص أن يعجب لومبوك أيضًا إلقاء نظرة على Scala. العديد من الأفكار الجيدة التي تجدها في لومبوك هي جزء من لغة سكالا.

على سؤالك: من الأسهل بالتأكيد جعل مطوريك يحاولون لومبوك من سكالا. جربه وإذا أعجبهم ، جرب Scala.

مثل إخلاء المسؤولية: أنا أحب جافا ، أيضا!

Answer 9

لقد استخدمت Lombok في جميع مشاريعي تقريبًا لمدة عام واحد ، لكن للأسف قمت بإزالته. في البداية ، كانت طريقة تنمية نظيفة للغاية ولكن إنشاء بيئة التطوير لأعضاء الفريق الجدد ليس سهلاً ومباشرًا. عندما أصبح صداع ، أزلته للتو. لكنه عمل جيد ويحتاج إلى المزيد من البساطة للإعداد.

Answer 10

عندما عرضت المشروع على فريقي ، كان الحماس مرتفعًا ، لذلك أعتقد أنك يجب ألا تخاف من استجابة الفريق.

• بقدر العائد على الاستثمار ، فهو عبارة عن اندماج ، ولا يتطلب أي تغيير في شكله الأساسي. (مجرد إضافة تعليق توضيحي واحد إلى صفك)

• وأخيراً ، إذا قمت بتغيير رأيك ، يمكنك تشغيل Unlomombok ، أو السماح لـ IDE بإنشاء هؤلاء المستقلين ، و getters ، و ctors ، (والتي أعتقد أن لا أحد سوف يطلب بمجرد أن يروا مدى وضوح pojo الخاص بك)

Answer 11

أراد استخدام لومبوك @ToString ولكن سرعان ما واجهت أخطاء ترجمة عشوائية على إعادة بناء المشروع في Idea Intellij. اضطررت إلى الوصول إلى التجميع عدة مرات قبل أن يكتمل التجميع الإضافي مع النجاح.

حاول كل من Lombok 1.12.2 و 0.9.3 مع Intellij Idea 12.1.6 و 13.0 دون أي مكون إضافي Lombok تحت JDK 1.6.0_39 و 1.6.0_45.

اضطررت إلى نسخ الطرق التي تم إنشاؤها يدويًا من مصدر Delomboked ووضع Lombok حتى يتم تعليقها حتى أوقات أفضل.

تحديث

تحدث المشكلة فقط مع تمكين الترجمة المتوازية.

قدم مشكلة:https://github.com/rzwitserloot/lombok/issues/648

تحديث

علق Mplushnikov على 30 يناير 2016:

الإصدار الأحدث من Intellij لم يعد لديه مثل هذه القضايا بعد الآن. أعتقد أنه يمكن إغلاقه هنا.

تحديث

أوصي بشدة بالتبديل من Java+Lombok إلى كوتلين اذا كان ممكنا. كما تم حلها من الألف إلى الياء جميع مشكلات جافا التي يحاول لومبوك أن تدور حولها.

Answer 12

إن رأيي في Lombok هو أنه يوفر مجرد اختصارات لكتابة رمز Bolilerplate Java.
عندما يتعلق الأمر باستخدام اختصارات لكتابة رمز Java Bolilerplate ، فإنني سأعتمد على هذه الميزات التي توفرها IDE - كما هو الحال في Eclipse ، يمكننا الانتقال إلى مصدر القائمة> إنشاء Getters و Petters لإنشاء getters والمستقبين.
لن أعتمد على مكتبة مثل لومبوك لهذا:

1. إنه يلوث الكود الخاص بك بطبقة غير توجيهية من بناء الجملة البديلة (اقرأ @Getter, @Setter, ، إلخ. التعليقات التوضيحية). بدلاً من تعلم بناء جملة بديل لـ Java ، أود أن أتحول إلى أي لغة أخرى توفر لومبوك مثل بناء الجملة.
2. يتطلب Lombok استخدام IDE المدعوم من Lombok للعمل مع الكود الخاص بك. يقدم هذا التبعية خطرًا كبيرًا لأي مشروع غير تافدي. هل لدى مشروع LOMBOK مفتوح المصدر موارد كافية للحفاظ على تقديم الدعم للإصدارات المختلفة من مجموعة واسعة من Java IDE المتاحة؟
3. هل لدى مشروع Lombok المصدر المفتوح موارد كافية للحفاظ على تقديم الدعم للإصدارات الأحدث من Java التي ستأتي في المستقبل؟
4. أشعر أيضًا بالتوتر من أن Lombok قد يقدم مشكلات التوافق مع الأطر/المكتبات المستخدمة على نطاق واسع (مثل Spring و Hibernate و Jackson و Junit و Mockito) التي تعمل مع رمز البايت الخاص بك في وقت التشغيل.

الكل في الكل لا أفضل "التوابل" بلدي جافا مع لومبوك.

Answer 13

لقد واجهت مشكلة مع لومبوك و جاكسون CSV, ، عندما قمت بتنظيم كائني (Java Bean) إلى ملف CSV ، والأعمدة التي تكرارها ، ثم قمت بإزالة شرح @Data الخاص بـ Lombok بشكل جيد.

Answer 14

أنا لا أوصي به. اعتدت على استخدامه ، ولكن عندما أعمل مع NetBeans 7.4 كان عبث رموزاتي. عليّ إزالة لومبوك في جميع الملفات في مشاريعي. هناك Delombok ، ولكن كيف يمكنني التأكد من أنها لن تفسد رموزاتي. لا بد لي من قضاء أيام فقط لإزالة لومبوك والعودة إلى أنماط جافا العادية. أنا فقط حار جدا ...

Answer 15

لم أحاول استخدام Lombok بعد - لقد كان/كان التالي في قائمتي ، لكن يبدو أن Java 8 تسببت في مشاكل كبيرة لذلك ، وكان العمل العلاجي لا يزال قيد التقدم منذ أسبوع. مصدري لذلك https://code.google.com/p/projectlombok/issues/detail؟id=451 .