سؤال

أنا حاليا على تطوير مشروع مكتوب بلغة جافا.لدينا مجموعة من الخوارزميات مكتوب في C/C++ (على الأقل بضع مئات) التي تحتاج إلى إدراجها في المشروع.لدينا خياران لاستخدام JNI أن نطلق على هذا القانون ، أو لإعادة كتابة الخوارزميات في جاوة.

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

في هذه الحالة ، JNI جعل هذه المهمة سهلة ؟ أو من شأنه أن يسبب صداع أكثر من إعادة كتابة التعليمات البرمجية في جافا ؟


تحرير #1: ذات السؤال - فائدة JNI


تحرير #2: لمعلوماتك - لدينا جافا المشروع ليس من المفترض أن تكون محمولة في أي شكل من الأشكال.التي قد تقضي على واحدة من سلبيات JNI في أنه من المفترض أن يقلل من قابلية.

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

المحلول

الجواب البسيط هو: إذا كان رمز ستكون دعا الكثير والأداء المسائل ثم تحويله إلى جاوة.

أكثر تعقيدا الإجابات:

  • إذا كانت المكتبة بسهولة ملفوفة في JNI ثم انتقل مع JNI
  • إذا كانت الاختبارات لديك C/C++ رمز تحويلها بسهولة إلى جافا ثم انتقل الميناء

وأود أن تفعل ما يلي:

  • تأخذ واحدة من خوارزميات والتفاف عليه في JNI
  • خذ نفس خوارزمية وتحويله إلى جافا
  • انظر الذي هو أكثر من الألم
  • إذا سرعة المسائل ثم تعريف كل من الإصدارات والتي ترى منهم هو مقبول.

نصائح أخرى

أعتقد أن الجواب يكمن في كمية من اقتران سيكون هناك بين الدعوة كود جافا و الاحتجاج C/C++ رمز في مستوى الجهد كتابة سيترتب على ذلك.إذا كان لديك التعليمات البرمجية C يأخذ عدد قليل من الاعداد الصحيحه ، يفعل بعض شعر الحساب ، ويعود آخر int.استخدام JNI.إذا كان هناك الكثير من مجمع ذهابا وإيابا ، ولكن خوارزميات بسيطة ومعقولة ، كتابة 'م.خط الصدع هو JNI الصدد.إذا كان هذا هو الذهاب إلى أن تكون معقدة ، قد ينتهي كتابة أكثر JNI واجهة رمز من خوارزمية رمز إعادة كتابة.

إذا كان "خوارزميات" هي وتعبئتها بشكل جيد, ربما كان من الممكن لخلق بعض التلقائي الغراء رمز خلال JNI?التي من شأنها خفض مخاطر الأخطاء (خلق مئات من المكونات الفردية يدويا تبدو محفوفة بالمخاطر) ، وجعل تكلفة مستقلة من عدد من الخوارزميات إضافة أكثر أو أقل.

إعادة كتابة مئات من مكونات يبدو في غاية الخطورة ، أود أن أوصى بالتأكيد على الأقل التحقيق JNI عن كثب الأولى.

ماذا I/O متطلبات القيام خوارزميات مع بقية المشروع ؟ إذا فهي إلى حد ما المتباعدة ، ربما سيكون من الممكن لتشغيل لهم قائمة بذاتها منفصلة البرامج التذرع العمليات الفرعية من جاوة باستخدام على سبيل المثالstdio لتبادل البيانات ؟

أعتقد أنك سوف تجد أن استخدام JNI ليست صعبة كما يبدو قبل الغوص في.هناك بعض المقايضات والقيود ولكن في العام JNI يعمل بشكل جيد و معقول سهلة للاستفادة كما كنت تنوي.

كما أن البعض قال أفضل حالة JNI هو:

  • مجمع التعليمات البرمجية الأصلية (نقاط مكافأة إذا كان هذا القانون قد ثبت بالفعل موثوقة جدا)
  • الحد الأدنى ذهابا وإيابا بين جافا البرمجية الأصلية (كنت ترغب في تقليل الرحلات عبر طبقة JNI)
  • معقول بسيطة استدعاء واجهة البرمجية الأصلية (أو أيضا إلى جافا إذا كنت من مواليد رمز يحتاج إلى الاستفادة من كائنات جافا/طرق)

من الممكن بالتأكيد أن أتمتة أو شبه أتمتة إنشاء طبقة JNI معقول منظم مجموعة من المكونات الأصلية.من شأنه أن يكون جيدا يستحق ذلك إذا كان عدد من مكونات التفاف كبير.

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

كتابة عدد كبير من C/C++ الخوارزميات في جافا يبدو أكثر خطورة من استخدام JNI.دون معرفة تفاصيل من الصعب قياس ، بالطبع ، ولكن هناك خلافات خفية بين التقنيات التي يمكن أن أتصور التأثير الفعلي في تنفيذ خوارزمية ، ناهيك عن مجرد محض هندسة الجهد و احتمال الخطأ.

النظر في نهائي الحياة في المستقبل من هذه الخوارزميات أو مكونات ذات الصلة.هو مجموعة من خوارزميات أكثر أو أقل اكتمالا ، أو يمكنك الاستمرار في إضافة ؟ وفي كلتا الحالتين هناك قوي الصيانة و/أو التنمية المستقبلية أسباب تفضيل تقنية واحدة على الأخرى ؟ على سبيل المثال, إذا كل شيء آخر هو في جافا جميع خوارزميات جديدة سوف تكون في جافا تقريبا كل الفريق تقريبا دائما الترميز في جاوة ، reimplementing في جافا يبدأ لتبدو أكثر جاذبية على المدى الطويل.

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

كنت لا تزال تنظر بجدية في الذهاب JNI ، لا سيما إذا كنت قادرة على تقليل عدد من اللغة عبر الواجهات.

إذا ، على سبيل المثال ، هناك كومة كبيرة من C الوظائف التي لها نفس المدخلات والمخرجات ، ولكن العمل المختلفة على المدخلات ، والتفاف أن في واحد JNI المجمع مع معلمة إضافية لتحديد أي خوارزمية معينة للاستخدام.

إذا كنت تخطط لكتابة المشاريع المستقبلية في جافا, بدلا من C/C++.أنا لدغة الرصاصة الآن منفذ رمز إلى جاوة.طال الانتظار والأسوأ أنها سوف تصبح.JNI يبدو جذابا في هذه الحالة, ولكن بعد ذلك سيكون لديك مشكلة وجود شخص للحفاظ على رمز C++ عندما يكون الجميع على متعة جديدة جافا مشاريع.

إذا كان هذا هو مرة واحدة جافا المشروع ، ثم لماذا الكتابة في جافا ؟

الجسر بين C و Java مكلفة, حتى إذا كان لديك لتمرير الكثير من البيانات ذهابا وإيابا هناك أي فوز في الاتصال ج على JNI.

لقد رأيت JNA سرد بديل معقول JNI مع الكثير ألم أقل أن أساليب الدعوة في DLL/المكتبة المشتركة من جاوة في انعكاس مثل الطريقة.أنا لم أجربها بعد.

قد ترغب في النظر في تجميع الخاص بك التعليمات البرمجية C كما لينكس MIPS الثنائية التي يمكن أن تفسر في جاوة.معقول سريع قليلا من الصعب إعداد بشكل صحيح.انظر http://nestedvm.ibex.org/

أيضا يمكنك استخدام llvm الخلفية إلى دول مجلس التعاون الخليجي إلى ترجمة إلى lowlevel bytecodes التي يمكن تفسيرها في جافا.وهذا هو أيضا النهج المتبع مع iPhone SDK afaik على نظام التشغيل Mac OS X. http://llvm.org/

قراءة جويل receint آخر يوم "دفع أسفل الديون التقنية"ثم المضي قدما وتحويل ذلك الآن بدلا من دفع الفائدة على مدى السنوات القليلة القادمة ثم يؤتي ثماره.

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

لقد كنت في هذا الوضع.أقترح عليك أن تعتاد على استخدام متعددة الخيوط هياكل البيانات التي تتوفر في جافا.في هذه المرحلة لن ترغب في العودة إلى هياكل البيانات C++ أي أكثر من ذلك.

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

عندما كنت جالسا في C/C++ code, كنت أفكر أن كنت تريد أن تعلق على ذلك.كنت أفكر كل الحب الذي وضعت فيه.في بضع سنوات ، عليك أن تدرك أن من عقد على ذلك و باستخدام JNI التي قمت بإنشائها وحش.في كل مرة تحصل عملية تحطم ستندم باستخدام JNI.بعد تحديد عملية تحطم, شخص ما سوف ترغب في تعديل خوارزمية في C++ و أنت تريد أن خنق لهم.سيكون لديهم ذريعة مريحة مثل "أنا لا تستخدم جافا بعد".

نظرة ثابتة هياكل البيانات في جافا.لا أعتقد حتى عن سرعة هذه العجوز C/C++ خوارزميات تنفيذ.لقد وجدت أن بلدي قانون جديد بعيد تسير أي من C/C++ code.

كتابة وحدة الاختبارات.استخدام NetBeans.

مع أطيب التحيات ،

-إس تي أو إس إتش

تعطي JNI المحاولة.ثم إذا ما واجهت أي مشاكل يمكنك كتابة إشكالي أو التفاف JNI المكالمات مع webservices ونشرها على صناديق مختلفة أو الظاهري مربعات.

إذا كان هذا هو ويندوز فقط و هم بالفعل في DLL, ربما JNA سيكون من الاستخدام.(إذا كان الأداء ضرب على المكالمات من خلال وظيفة الجيش الشعبي اليوغوسلافي ليست سيئة للغاية)

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