سؤال

لدينا حزمة تنتهي باستثناء مثل

package a.b.c.exception;

لم يكن لدى قاعدة التعليمات البرمجية أي مشاكل حتى Eclipse 3.3 ، ولكن عندما انتقلنا إلى Eclipse 3.4 ، بدأت في إعطاء أخطاء تتعلق بهذه الحزمة:

"The package a.b.c.exception collides with a type"

عندما أقوم بإعادة تشكيل اسم الحزمة إلى Abcexceptions ، لا توجد مشاكل. هل هذا بسبب خطأ في Eclipse 3.4 أم أن هناك بعض الإعدادات لتصحيح هذا السلوك؟

هل كانت مفيدة؟

المحلول 5

لقد غيرت أحد خيار التجميع في Eclipse واختفت المشكلة. تحت خصائص مساحة العمل: جافا مترجم -> الأخطاء/التحذيرات -> تغيير "الاستيراد غير المستخدم" من "تحذير" إلى "تجاهل".

نصائح أخرى

هذا لأن لديك فصل اسمه exception (مع الحالة السفلية "E") في a.b.c حزمة وحزمة مسماة a.b.c.exception.

إنه يسبب تصادمًا لأنه إذا كان لديك الرمز a.b.c.exception.doSomething(); - هل هذا يعني أنك تريد استدعاء الثابت doSomething() الطريقة في a.b.c.exception صف دراسي؟ أم أنه يعني أن هناك فئة تسمى a.b.c.exception.doSomething أنك تحاول استدعاء مُنشئ؟

التمسك مع اتفاقيات تسمية Java - الحزم جميع الأحرف الصغيرة ، والفئات التي تبدأ بحالة كبيرة وحالات الجمال بعد - ولن ترى هذه المشكلة أبدًا.

========== edit ===========

هذا هو فقط شرعي سبب هذا الخطأ يجب أن يظهر ...

لا يجب أن يكون في مشروعك مباشرة ، فقد يكون في مشروع أو مكتبة أخرى يعتمد عليها مشروعك. يجب أن يوضح لك هذا أي حوادث للفئة في أي مكان على مسار البناء أو مشروعك: اضغط على زر البحث عن المصباح في شريط أدوات Eclipse -> اختر "Java Search" - حدد "اكتب" في "البحث عن" -> تأكد من تحديد جميع الخيارات ل "البحث في".

هل تستخدم أي أدوات تنشئ فصولًا؟ هل يمكنهم وضعهم في دليل بناء مشروعك؟ عندما ترى الخطأ ، إذا ذهبت إلى دليل بناء المشروع ، وانتقل إلى الدليل A/B/C/هل ترى ملف .class لـ "استثناء"؟

بالطبع ، يمكن أن يكون للكسوف بشكل عام خطأ (على الرغم من أنني أتوقع أن يكون هناك تقرير خطأ في Eclipse 3.4 وستتمكن من العثور على المزيد من الشكاوى إذا كان ...) ، يمكن كسر تثبيت الكسوف الخاص بك في بعض الطريق (هل يمكن لأي شخص آخر أن يفتح مشروعك في Eclipse 3.4؟ هل يمكنك إجراء تثبيت نظيف Eclipse 3.4 في دليل آخر؟ هل يظهر الخطأ هناك؟) ، أو يمكن أن يفسد مشروعك بطريقة ما (إنشاء مشروع جديد بدون تبعيات بخلاف JDK ، قم بإنشاء حزمة Abcexception في مشروعك الجديد ، قم بإنشاء فصل في مشروعك إلى import a.b.c.exception.*; ومعرفة ما إذا كان الخطأ يحدث.).

في Java ، لا يمكنك الحصول على اسم الفصل هو نفس اسم الحزمة.

هذا يعني أن حزمة JDT يجب أن تنفذ هذه القاعدة فقط في 3.4

نرى علة 63668 على سبيل المثال.


كما يعلق نيت:

لن يمنعك الاستثناء المسمى الفصل من إنشاء استثناء الحزمة.
القضية تهم.

تذكر أيضًا أن الاسم الكامل للفصل يتضمن الحزمة الموجودة فيه.
لذا a.b.SomeClass (اسم الفصل) يختلف عن x.y.SomeClass (اسم الحزمة).
لن يكون هناك تصادم اسم هنا.

يجب أن يتطابق اسم الفصل واسم الحزمة في كل من الحالة والحزمة للتسبب في هذا الخطأ.

نرى إجابته الأكثر دقة.

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

لإعادة الصياغة ، كان Eclipse يخبرني أنه كان لدي حزمة/نوع اشتباك لـ ABCD عند تجميع ABCDlondon. كشف إجراء بحث Java على الرمز الخاص بـ ABCD أن Eclipse اعتقد أن تعليق Javadoc في Abcparis كان مباراة. احتوى تعليق Javadoc {@ Link D.Newyork}. عندما قمت بتغيير تكنولوجيا المعلومات لقراءة {link abcdnewyork} تم حل خطأ التجميع.

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

أعلم أن هذا سيبدو سخيفًا ، وربما يكون بسيطًا جدًا ، لكنني حللت نفس رسالة الخطأ بالضبط بواسطة:

  • حذف السطر الكامل لاسم الحزمة الذي يسبب رسالة الخطأ.
  • إن حفظ ملف .java (يؤدي هذا إلى خطأ جديد على نفس السطر يوضح "الحزمة المعلنة" "لا يتطابق مع الحزمة المتوقعة") ، وهو ما يجب القيام به.
  • إعادة تحديد اسم الحزمة الأصلي على نفس السطر.
  • حفظ ملف .java.

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

الكتابة الآمنة والترميز السريع.

-جود

إذا كان لديك فئة foo ، فلا يمكن أن يكون لديك حزمة تنتهي بـ Foo ، مثل com.my.foo.
أيضًا إذا كنت تستخدم أسلوب Maven ، فلديك موارد في مشروعك تحت شيء مثل SRC/Main/Resources
تحتوي المجلدات الموجودة في مواردك أيضًا على نمط حزمة وهناك ، أيضًا ، لا يمكن أن يكون لديك مجلد يحتوي على اسم فصلك.

ستواجه بالتأكيد هذه المشكلة عند تطوير مكون إضافي Jenkins وفقًا للاتفاقيات الموصى بها.
إذا اتبعت اتفاقيات Jenkins ، وقمت بإنشاء منشئ في فصل يدعى MyBuilder في الحزمة XY ، فمن المفترض أيضًا أن تضع. Jelly في مجلد موارد يدعى XymyBuilder. هذا سيؤدي إلى المشكلة أعلاه.
ومع ذلك ، إذا قمت بتسمية مجلد المورد الخاص بك XymyBuilder (لاحظ الحالة السفلية "M" في MyBuilder) ، على عكس الاتفاقية الموصى بها ، سيظل المكون الإضافي يعمل كما تقصد

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top