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

فشلت CI ، لكن لا يمكنني رؤية كيف كسرناها في 1.2.1. أستطيع أن أرى أن getDeclaredMethods () لا تتضمن طرقًا هي تطبيقات افتراضية. (لم يتم الإعلان عنها في الفصل أو الأنواع الفائقة).

هناك بعض النقاش في https://blog.jooq.org/2018/03/28/correct-reflective-access-to-interface-default-methods-in-java-8-9-10/ - أنا لا أفكر في هذا هي ذات الصلة.

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

هذا هو مؤشر ترابط stackoverflow الأكثر صلة الذي وجدته: https://stackoverflow.com/questions/28400408/what-is-the-new-way-of-getting-all-methods-of-a-class-including-inherited- ديفاو

يبدو أنه قد تكون هناك بعض الاختلافات في تطبيقات JVM المختلفة ...

إنه يعمل إذا قمت بالبث إلى java.util.Collection أولاً ، لكن لا ينبغي أن يكون ضروريًا ...: /

أعتقد أيضًا أنه بسبب استخدام getDeclaredMethods بدلاً من getMethods ، حاولت السير في جميع الواجهات ولكن بطريقة ما لم أجد واجهة المجموعة في getInterfaces () ...

حسنًا ، يبدو أن هذا يعمل ... لست متأكدًا تمامًا من السبب.
https://github.com/kivy/pyjnius/pull/466/files#diff -06f2b31838f083623d82353f734d644a

تحرير: اه ، حفظ ل segfault… https://github.com/kivy/pyjnius/runs/348651345
حاول الركض مرة أخرى في حالة حدوث خلل ، وتحطمت مرة أخرى على ubuntu ، و python3.8 ، و java 10 ...
Edit2: مرتبك للغاية ، كل التوليفات الحالية عملت عندما استبعدت 3.8 / java10 / ubuntu معًا ، ثم قمت بتمكين java 9 و 11 ، وحصلت على نفس التعطل مع 3.7 / 11 / ubuntu ... حسنًا على الأقل يمكنني تثبيت openjdk-11-jdk على ubuntu الخاص بي واختبر مع python3.7 بسهولة… ... وهو يعمل. grmbl.

https://dev.azure.com/conda-forge/feedstock-builds/_build/results؟buildId=100815&view=logs&j=696704cc-6fef-57a3-ea36-f27779b8cd5e&t=06421391-4b55-523d-a804-5e1908bf
بشكل مفاجئ ، يبدو أن بناء conda-forge على Linux يحتوي أيضًا على بعض segfaults على 1.2.1 ، لذلك ربما كانت المشكلة موجودة قبل التغيير الذي أجريته.

يعمل التصحيح بالنسبة لي على Collab

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

آسف لترك هذا الأمر باقٍ ، ليس لدي أي فكرة حقًا ما الذي يمنع CI من المرور ، ولا أحب حقًا تعطيل جزء من الأهداف لمجرد إسكات خطأ غير مفهوم ، أوافق على ترك هذا bitrot ليس أفضل ولكن أنا ' م لست متأكدا من كيفية المضي قدما من هذا.

لقد تساءلت عما إذا كانت هذه مشكلة التزامن وفقًا للرقم 480 # ، لكنني لا أعتقد أن pytest متزامن افتراضيًا.

حاولت الاستنساخ محليًا ، لكنني لم أنجح في إعادة إنتاج # 480. هذا كان أمري - إنها صورة مبنية على دبيان:

docker run -i continuumio/anaconda3 /bin/bash <<EOF

cat /etc/os-release
apt-get update
mkdir /usr/share/man/man1
apt-get -y install openjdk-11-jdk-headless gcc ant

conda create -y -n pyjnius python=3.7.5
conda activate pyjnius

git clone https://github.com/kivy/pyjnius.git
cd pyjnius/
python -m pip install -U setuptools cython
python setup.py bdist_wheel
pip install --timeout=120 .[dev,ci]
ant all
cd tests/
CLASSPATH="../build/test-classes:../build/classes" PYTHONPATH=/opt/conda/envs/pyjnius/lib/python3.7/site-packages/ pytest -v
cd ../
git checkout -b issue_465 origin/issue_465

python setup.py bdist_wheel
pip install --timeout=120 .[dev,ci]
ant all
cd tests/
CLASSPATH="../build/test-classes:../build/classes" PYTHONPATH=/opt/conda/envs/pyjnius/lib/python3.7/site-packages/ pytest -v

EOF

تم اجتياز جميع الاختبارات على مستوى الماجستير وعلى الفرع.

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

آسف لترك هذا الأمر باقٍ ، ليس لدي أي فكرة حقًا ما الذي يمنع CI من المرور ، ولا أحب حقًا تعطيل جزء من الأهداف لمجرد إسكات خطأ غير مفهوم ، أوافق على ترك هذا bitrot ليس أفضل ولكن أنا ' م لست متأكدا من كيفية المضي قدما من هذا.

هل أقترح إعادة إجراء اختبارات CI؟ هل يمكننا محاولة تضييق ذلك - هل هي مشكلة في هذا التصحيح ، أم مشكلة في إصدار سابق؟

للعودة إلى هذا:

لا أعتقد أن خلط getDeclaredMethods() و getMethods() هو الحل. getMethods() كافٍ.

حالات الاختبار الخاصة بي لهذا هي:

 def test_super_interface(self):
        LinkedList = autoclass('java.util.LinkedList')
        words = LinkedList()
        words.add('hello')
        words.add('world')
        q = cast('java.util.Queue', words)
        self.assertEqual(2, q.size())
        self.assertIsNotNone(q.iterator())

    def test_super_object(self):
        LinkedList = autoclass('java.util.LinkedList')
        words = LinkedList()
        words.hashCode()

    def test_super_interface_object(self):
        LinkedList = autoclass('java.util.LinkedList')
        words = LinkedList()
        q = cast('java.util.Queue', words)
        q.hashCode()

فشل مختلف عندما نستخدم getDeclaredMethods () فقط.

مشكلتي الوحيدة مع getMethods() هي أن test_inheritance.py فشل. هذه مشكلة هامشية فقط - org.jnius.Child's ثابت newInstance() يتجاوز طريقة org.jnius.Parent newInstance() طريقة. ما يحدث هو أن getMethods() يرى كلا الطريقتين newInstance() ، لذلك يقوم ببناء JavaMultipleMethod. هذا خطأ: Child.newInstance() يجب إخفاء Parent.newInstance() - راجع https://www.java67.com/2012/08/can-we-override-static-method-in-java.html. لقد تحققت أيضًا من ذلك باستخدام Jshell:

jshell> org.jnius.Child.newInstance()
$3 ==> org.jnius.Child<strong i="24">@506c589e</strong>

مرحبًا tshirtman ، أرى أنك ملتزم بـ getMethods (). أوصي بحالات الاختبار الإضافية المذكورة أعلاه أيضًا.
لم أكن متأكدًا من كيفية حل الطريقة الثابتة لإخفاء Child.newInstance () الذي يجب أن يخفي Parent.newInstance (). أعتقد أنه سيتعين عليك إعادة ترتيب تكرار الفئات والواجهات في autoclass () - قم بالسير في الشجرة للحصول على الفئات ، ثم قم بتطبيقها بترتيب عكسي ، أي البدء في java.lang.Object.

حسنًا ، فإن إضافة هذا الاختبار تُظهر أن الكائن المصبوب حاليًا كفئة آلية java.util.Queue لا يحتوي على سمة size ، وهذا خطأ.
أنا أتفق مع تحليلك ، والبحث العكسي ، واستبدال الأساليب الأبوية بتوقيع متطابق بدلاً من إنشاء JavaMultipleMethod ، والتي تبدو وكأنها استراتيجية جيدة.

اجتاز 501 جميع الاختبارات. إغلاق هذه القضية. (الحمد).

الحقول المحمية لا تزال مفقودة!

يؤدي تغيير هذا السطر من public إلى protected فشل الاختبار.

هناك مناقشة حول # 500 حول ما إذا كان يجب كشف الطرق / الحقول الخاصة / المحمية على الإطلاق.

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

يبدو أنه صحيح بالنسبة للطرق ، لكن من الواضح أنه ليس صحيحًا (وربما لم يكن كذلك أبدًا؟) بالنسبة للمجالات

لقد نجحت مع <1.2.1 ، لذا أتوقع أن تعمل في> 1.2.1 ، <2.0 أيضًا حتى لو لم تكن تعمل مع أي إصدار.