لماذا نحتاج إلى لغات JVM أخرى؟

Question

أرى هنا أن هناك عددًا كبيرًا من اللغات بخلاف Java التي تعمل على JVM.أنا في حيرة من أمري بشأن المفهوم الكامل للغات الأخرى التي تعمل في JVM.لذا:

ما هي ميزة وجود لغات أخرى لـ JVM؟

ما هو المطلوب (بمصطلحات عالية المستوى) لكتابة لغة/مترجم لـ JVM؟

كيف تكتب/تترجم/تشغل التعليمات البرمجية بلغة (بخلاف Java) في JVM؟

---

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

كيف يتفاعل تطبيق مكتوب بلغة JPython، على سبيل المثال، مع تطبيق Java؟

أيضًا، هل يمكن لتطبيق JPython استخدام أي من وظائف/كائنات JDK؟؟

ماذا لو كانت كود Jaskell، ألن تجعلها حقيقة أنها لغة وظيفية غير متوافقة مع JDK؟

Answer 1

لمعالجة أسئلتك الثلاثة بشكل منفصل:

ما هي ميزة وجود لغات أخرى لـ JVM؟

هناك عاملان هنا.(1) لماذا تستخدم لغة أخرى غير Java لـ JVM، و(2) لماذا تعمل لغة أخرى على JVM، بدلاً من وقت تشغيل مختلف؟

1. لغات أخرى يمكن أن تلبي احتياجات أخرى.على سبيل المثال، لا يوجد دعم مدمج لـ Java الإغلاق, ، وهي ميزة غالبًا ما تكون مفيدة جدًا.
2. اللغة التي يتم تشغيلها على JVM هي لغة ثانوية متوافقة مع أي لغة أخرى تعمل على JVM، مما يعني أن التعليمات البرمجية المكتوبة بلغة واحدة يمكن أن تتفاعل مع مكتبة مكتوبة بلغة أخرى.

ما هو المطلوب (بمصطلحات عالية المستوى) لكتابة لغة/مترجم لـ JVM؟

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

كيف تكتب/تترجم/تشغل التعليمات البرمجية بلغة (بخلاف Java) في JVM؟

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

الإجابة على أسئلة المتابعة الخاصة بك:

كيف يتفاعل تطبيق مكتوب بلغة JPython، على سبيل المثال، مع تطبيق Java؟

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

from java.net import URL
u = URL('http://jython.org')

أيضًا، هل يمكن لتطبيق JPython استخدام أي من وظائف/كائنات JDK؟

نعم، انظر أعلاه.

ماذا لو كانت كود Jaskell، ألن تجعلها حقيقة أنها لغة وظيفية غير متوافقة مع JDK؟

لا.يقوم Scala (الرابط أعلاه) على سبيل المثال بتنفيذ ميزات وظيفية مع الحفاظ على التوافق مع Java.على سبيل المثال:

object Timer {
  def oncePerSecond(callback: () => unit) {
    while (true) { callback(); Thread sleep 1000 }
  }
  def timeFlies() {
    println("time flies like an arrow...")
  }
  def main(args: Array[String]) {
    oncePerSecond(timeFlies)
  }
}

Answer 2

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

بشكل عام، كتابة "مترجم" للغة أخرى لتشغيلها على JVM (أو على .Net CLR) هي في الأساس مسألة ترجمة تلك اللغة إلى كود جافا الثانوي (أو في حالة .Net, IL) بدلاً من التجميع /لغة الآلة.

ومع ذلك، فإن الكثير من اللغات الإضافية التي تتم كتابتها لـ JVM لم يتم تجميعها، بل تم تفسيرها بدلاً من لغات البرمجة النصية...

Answer 3

عند قلب هذا الأمر رأسًا على عقب، ضع في اعتبارك أنك تريد تصميم لغة جديدة وتريد تشغيلها في وقت تشغيل مُدار باستخدام JIT وGC.ثم ضع في اعتبارك أنه يمكنك:

(أ) اكتب وقت التشغيل المُدار (VM) الخاص بك وقم بمعالجة جميع أنواع المشكلات الصعبة تقنيًا والتي ستؤدي بلا شك إلى العديد من الأخطاء والأداء السيئ والترابط غير المناسب وقدر كبير من جهد قابلية النقل

أو

(ب) تجميع لغتك في كود ثانوي يمكن تشغيله على Java VM الذي يعد بالفعل ناضجًا وسريعًا ومدعومًا على عدد من الأنظمة الأساسية (أحيانًا مع أكثر من خيار واحد لتطبيق البائع).

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

Answer 4

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

فائدة أخرى هي أنه يتيح لك تشغيل بعض أطر عمل الويب المكتوبة بلغة Ruby ala JRuby (ويعرف أيضًا باسم Rails)، أو Grails (Groovy on Railys أساسًا)، وما إلى ذلك.على منصة استضافة مثبتة والتي من المحتمل أنها قيد الإنتاج بالفعل في العديد من الشركات، بدلاً من الاضطرار إلى استخدام بيئات استضافة Ruby التي تمت تجربتها واختبارها تقريبًا.

لتجميع اللغات الأخرى، ما عليك سوى التحويل إلى Java byte Code.

Answer 5

سأجيب: "لأن جافا تمتصولكن مرة أخرى، ربما يكون هذا هو الحال واضح جدا … ;-)

Answer 6

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

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

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

Answer 7

تم تصميم لغات مختلفة لمهام مختلفة.في حين أن بعض مجالات المشاكل تناسب لغة Java تمامًا، إلا أن بعضها أسهل بكثير في التعبير عنها بلغات بديلة.أيضًا، بالنسبة للمستخدم المعتاد على Ruby وPython وما إلى ذلك، فإن القدرة على إنشاء Java bytecode والاستفادة من فئات JDK ومترجم JIT لها فوائد واضحة.

Answer 8

الإجابة على سؤالك الثاني فقط:

JVM هي مجرد آلة مجردة ونموذج تنفيذ.لذا فإن استهدافه باستخدام مترجم هو تمامًا مثل أي جهاز آخر ونموذج تنفيذ قد يستهدفه المحول البرمجي، سواء تم تنفيذه في الأجهزة (x86، CELL، إلخ) أو البرامج (parrot، .NET).JVM بسيط إلى حد ما، لذا فهو في الواقع هدف سهل إلى حد ما للمترجمين.أيضًا، تميل التطبيقات إلى امتلاك مترجمات JIT جيدة جدًا (للتعامل مع التعليمات البرمجية الرديئة التي ينتجها javac)، حتى تتمكن من الحصول على أداء جيد دون الحاجة إلى القلق بشأن الكثير من التحسينات.

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

Answer 9

يتم تحديد ما يمكن أن يفعله JVM من خلال الكود الثانوي الخاص بـ JVM (ما تجده في ملفات .class) بدلاً من اللغة المصدر.لذا فإن تغيير لغة التعليمات البرمجية المصدر عالية المستوى لن يكون له تأثير كبير على الوظائف المتاحة.

أما بالنسبة لما هو مطلوب لكتابة مترجم لـ JVM، فكل ما عليك فعله هو إنشاء ملفات bytecode / .class الصحيحة.تعتمد كيفية كتابة/ترجمة التعليمات البرمجية باستخدام مترجم بديل على المترجم المعني، ولكن بمجرد أن يقوم المترجم بإخراج ملفات .class، فإن تشغيلها لا يختلف عن تشغيل ملفات .class التي تم إنشاؤها بواسطة javac.

Answer 10

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

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

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

من وجهة نظر المستخدمين، ما عليك سوى كتابة التعليمات البرمجية وتشغيل ثنائيات المترجم، وستظهر ملفات .class التي يمكنك مزجها مع تلك التي ينتجها مترجم جافا الخاص بك.

Answer 11

إن لغات .NET مخصصة للعرض أكثر من كونها مفيدة فعليًا.لقد تم تدمير كل لغة لدرجة أنها جميعها تستخدم لغة C# بوجه جديد.

هناك مجموعة متنوعة من الأسباب لتوفير لغات بديلة لـ Java VM:

• JVM متعدد المنصات.أي لغة يتم نقلها إلى JVM تحصل على ذلك كمكافأة مجانية.
• هناك قدر لا بأس به من التعليمات البرمجية القديمة هناك.تعمل المحركات القديمة مثل ColdFusion بشكل أفضل بينما تقدم للعملاء القدرة على تحويل تطبيقاتهم ببطء من الحل القديم إلى الحل الحديث.
• تعتبر بعض أشكال البرمجة النصية أكثر ملاءمة للتطور السريع.على سبيل المثال، تم تصميم JavaFX مع أخذ التطوير الرسومي السريع في الاعتبار.وبهذه الطريقة يتنافس مع محركات مثل DarkBasic.(المعالجة هي لاعب آخر في هذا المجال.)
• يمكن أن توفر بيئات البرمجة النصية التحكم.على سبيل المثال، قد يرغب أحد التطبيقات في عرض بيئة تشبه VBA للمستخدم دون الكشف عن واجهات برمجة تطبيقات Java الأساسية.يمكن أن يوفر استخدام محرك مثل Rhino بيئة تدعم البرمجة السريعة والقذرة في صندوق حماية يتم التحكم فيه بعناية.
• البرامج النصية المفسرة تعني أنه ليست هناك حاجة لإعادة ترجمة أي شيء.لا حاجة لإعادة الترجمة إلى بيئة أكثر ديناميكية.على سبيل المثالعلى الرغم من استخدام OpenOffice لـ Java باعتبارها "لغة برمجة نصية"، إلا أن Java سيئة في هذا الاستخدام.يتعين على المستخدم المرور بجميع أنواع دورات إعادة الترجمة/إعادة التحميل غير الضرورية في بيئة البرمجة النصية الديناميكية مثل Javascript.
• وهو ما يقودني إلى نقطة أخرى.يمكن إيقاف محركات البرمجة النصية وإعادة تحميلها بسهولة أكبر دون إيقاف وإعادة تحميل JVM بالكامل.يؤدي هذا إلى زيادة فائدة لغة البرمجة النصية حيث يمكن إعادة ضبط البيئة في أي وقت.

Answer 12

من الأسهل على كاتب المترجم إنشاء رموز بايت JVM أو CLR.إنها تجريد أكثر نظافة وأعلى مستوى من أي لغة آلة.ولهذا السبب، أصبح تجربة إنشاء لغات جديدة أكثر جدوى من أي وقت مضى، لأن كل ما عليك فعله هو استهداف إحدى بنيات الأجهزة الافتراضية هذه وسيكون لديك مجموعة من الأدوات والمكتبات المتاحة بالفعل للغتك.لقد سمحوا لمصممي اللغة بالتركيز على اللغة أكثر من التركيز على البنية التحتية الداعمة الضرورية.

Answer 13

لأن عملية JSR تجعل Java ميتة أكثر فأكثر: http://www.infoq.com/news/2009/01/java7-updated

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

Answer 14

لقد جمعت Java قاعدة مستخدمين ضخمة عبر سبعة إصدارات رئيسية (من 1.0 إلى 1.6).قدرتها على التطور محدودة بسبب الحاجة إلى الحفاظ على التوافق مع الإصدارات السابقة لملايين لا تعد ولا تحصى من أسطر كود Java التي تعمل في الإنتاج.

هذه مشكلة لأن Java تحتاج إلى التطور إلى:

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

تعد متطلبات التوافق مع الإصدارات السابقة عائقًا أمام الحفاظ على القدرة التنافسية.

إذا قارنت Java بـ C#، فإن Java تتمتع بميزة المكتبات والأطر الناضجة والجاهزة للإنتاج، وعيوب من حيث ميزات اللغة ومعدل الزيادة في حصتها في السوق.هذا ما تتوقعه من المقارنة بين لغتين ناجحتين يفصل بينهما جيل واحد.

تتمتع أي لغة جديدة بنفس المزايا والعيوب التي تتمتع بها C# مقارنة بـ Java إلى حد كبير.تتمثل إحدى طرق تعظيم الميزة من حيث ميزات اللغة، وتقليل العيوب من حيث المكتبات والأطر الناضجة، في بناء لغة لجهاز افتراضي موجود وجعله قابلاً للتشغيل المتبادل مع التعليمات البرمجية المكتوبة لهذا الجهاز الظاهري.هذا هو السبب وراء النجاح المتواضع الذي حققه Groovy وClojure؛والإثارة حول سكالا.بدون JVM، لم يكن من الممكن أن تحتل هذه اللغات سوى مكانة صغيرة في قطاع سوقي متخصص للغاية، بينما مع JVM فإنها تحتل مكانة كبيرة في الاتجاه السائد.

Answer 15

يفعلون ذلك لمواكبة .Net..Net يسمح بـ C#، وVB، وJ# (سابقًا)، وF#، وPython، وRuby (قريبًا)، وc++.ربما أفتقد البعض.من المحتمل أن تكون بايثون هي الشركة الكبرى في مجال البرمجة النصية.

Answer 16

إلى حد ما، من المحتمل أن يكون هذا "سباق تسلح" ضد .NET CLR.

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

سأترك شخصًا أكثر تأهيلاً للحديث عما هو مطلوب لكتابة لغة/مترجم جديد.

أما بالنسبة لكيفية كتابة التعليمات البرمجية، يمكنك القيام بذلك في المفكرة/vi كالمعتاد!(أو استخدم أداة تطوير تدعم اللغة إذا كنت تريد القيام بذلك بالطريقة السهلة.) سيتطلب التجميع مترجمًا خاصًا للغة الذي سيقوم بتفسيرها وتجميعها في كود بايت.

نظرًا لأن Java تنتج أيضًا رمزًا ثانويًا من الناحية الفنية، فلن تحتاج إلى القيام بأي شيء خاص لتشغيلها.

Answer 17

والسبب هو أن منصة JVM تقدم الكثير من المزايا.

• عدد هائل من المكتبات
• درجة أوسع من تطبيقات المنصة
• أطر ناضجة
• الرمز القديم الذي هو بالفعل جزء من البنية التحتية الخاصة بك

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

بالإضافة إلى ذلك، غالبًا ما يكون التعبير عن بعض الأشياء بلغة ديناميكية أسهل من التعبير عنها في Java.إذا كان هذا هو الحال، يمكنك الذهاب في الاتجاه الآخر؛تستهلك بايثون/روبي المكتبات من جافا.

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