آلة جافا الافتراضية

الموسوعة الحرة
آلة جافا الافتراضية
مصممصن مايكروسستمز
أجزاء32 بت
قدَّم1994
إصدار20.0.1 [1]
يكتبالتكديس والتسجيل - التسجيل
الترميزعامل
التفرعالمقارنة والتفرع
الانديانيةكبير
يفتحنعم
السجلات
أغراض عامةمجموعة متغيرات لكل طريقة (حتى 65535 متغيرًا) بالإضافة إلى متغيرات محلية لكل طريقة (حتى 65535)
نظرة عامة على بنية آلة Java الافتراضية (JVM) المستندة إلى مواصفات آلة Java الافتراضية Java SE 7 Edition

آلة Java الافتراضية ( JVM ) هي آلة افتراضية تمكن الكمبيوتر من تشغيل برامج Java وكذلك البرامج المكتوبة بلغات أخرى والتي تم تجميعها أيضًا إلى بايت كود Java . يتم تفصيل JVM من خلال مواصفات تصف رسميًا ما هو مطلوب في تنفيذ JVM. يضمن وجود مواصفات قابلية التشغيل المتبادل لبرامج Java عبر تنفيذات مختلفة بحيث لا يحتاج مؤلفو البرامج الذين يستخدمون Java Development Kit (JDK) إلى القلق بشأن خصوصيات منصة الأجهزة الأساسية.

تم تطوير تنفيذ مرجع JVM بواسطة مشروع OpenJDK ككود مفتوح المصدر ويتضمن مُجمِّع JIT يسمى HotSpot . تعتمد إصدارات Java المدعومة تجاريًا والمتوفرة من Oracle على وقت تشغيل OpenJDK. Eclipse OpenJ9 هو JVM مفتوح المصدر آخر لـ OpenJDK.

مواصفات JVM

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

بدءًا من Java Platform, Standard Edition (J2SE) 5.0، تم تطوير تغييرات على مواصفات JVM ضمن عملية مجتمع Java باسم JSR 924. [3] اعتبارًا من عام 2006 ، يتم إجراء تغييرات على المواصفات لدعم التغييرات المقترحة على تنسيق ملف الفئة (JSR 202) [4] كإصدار صيانة لـ JSR 924. تم نشر مواصفات JVM على أنها الكتاب الأزرق ، [5] الذي تنص مقدمته على:

نعتزم أن تتضمن هذه المواصفات توثيقًا كافيًا لآلة Java Virtual Machine لتمكين تنفيذات الغرف النظيفة المتوافقة. توفر Oracle اختبارات للتحقق من التشغيل السليم لتنفيذات آلة Java Virtual Machine.

يُطلق على أحد JVMs من Oracle اسم HotSpot؛ أما الآخر، والذي ورثته من BEA Systems ، فهو JRockit . تمتلك Oracle العلامة التجارية Java وقد تسمح باستخدامها لإصدار شهادات لمجموعات التنفيذ على أنها متوافقة تمامًا مع مواصفات Oracle.

محمل الفئة

تُعد الفئة إحدى الوحدات التنظيمية لرمز البايت في JVM . يجب أن يكون تنفيذ محمل الفئة قادرًا على التعرف على أي شيء يتوافق مع تنسيق ملف فئة Java وتحميله . يحق لأي تنفيذ التعرف على أشكال ثنائية أخرى إلى جانب ملفات الفئة ، ولكن يجب أن يتعرف على ملفات الفئة .

يقوم محمل الفئة بأداء ثلاثة أنشطة أساسية بهذا الترتيب الصارم:

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

بشكل عام، هناك ثلاثة أنواع من محمل الفئة: محمل فئة التمهيد، ومحمل فئة الامتداد، ومحمل فئة النظام/التطبيق.

يجب أن يحتوي كل تطبيق لآلة افتراضية Java على محمل فئة تمهيد قادر على تحميل الفئات الموثوقة، بالإضافة إلى محمل فئة الامتداد أو محمل فئة التطبيق. لا تحدد مواصفات آلة Java الافتراضية كيفية تحديد محمل الفئة للفئات.

هندسة الآلة الافتراضية

تعمل JVM على أنواع محددة من البيانات كما هو محدد في مواصفات Java Virtual Machine. يمكن تقسيم أنواع البيانات [6] إلى أنواع بدائية ( أعداد صحيحة ، فاصلة عائمة، طويلة، إلخ) وأنواع مرجعية. كانت JVM السابقة عبارة عن آلات 32 بت فقط . يتم دعم longالأنواع double، التي هي 64 بت ، بشكل أصلي، ولكنها تستهلك وحدتين من التخزين في المتغيرات المحلية للإطار أو مكدس المتعامل، حيث أن كل وحدة هي 32 بت. يتم تمديد الأنواع booleanو byteو shortو و جميعها بالإشارة (باستثناء تلك الممتدة إلى الصفر ) ويتم تشغيلها كأعداد صحيحة 32 بت، مثل الأنواع. تحتوي الأنواع الأصغر فقط على عدد قليل من التعليمات الخاصة بالنوع للتحميل والتخزين وتحويل النوع. يتم تشغيلها كقيم 8 بت، حيث يمثل 0 ويمثل 1 . (على الرغم من أنه تم التعامل معه كنوع منذ أن أوضحت مواصفات آلة Java الافتراضية، الإصدار الثاني هذه المشكلة، إلا أنه في الكود المجمّع والمنفذ لا يوجد فرق كبير بين a وa باستثناء تشويه الاسم في توقيعات الطريقة ونوع المصفوفات المنطقية. يتم تشويه s في توقيعات الطريقة كـ بينما يتم تشويه s كـ . تحمل المصفوفات المنطقية النوع ولكنها تستخدم 8 بتات لكل عنصر، ولا تحتوي JVM على قدرة مضمنة على حزم القيم المنطقية في مصفوفة بت ، لذا باستثناء النوع فإنها تؤدي وتتصرف بنفس الطريقة مثل المصفوفات. في جميع الاستخدامات الأخرى، يكون النوع غير معروف فعليًا لـ JVM حيث تُستخدم جميع التعليمات للعمل على القيم المنطقية أيضًا للعمل على s.) ومع ذلك، تدعم إصدارات JVM الأحدث (OpenJDK HotSpot JVM) 64 بت، لذلك يمكنك الحصول على JVM 32 بت/64 بت على نظام تشغيل 64 بت. الميزة الأساسية لتشغيل Java في بيئة 64 بت هي مساحة العنوان الأكبر. يتيح هذا حجم كومة Java أكبر بكثير وعدد أقصى متزايد من مؤشرات ترابط Java، وهو أمر مطلوب لبعض أنواع التطبيقات الكبيرة؛ ومع ذلك، هناك تأثير على الأداء في استخدام JVM 64 بت مقارنة بـ JVM 32 بت. charcharintbooleanbytefalsetruebooleanbooleanbytebooleanZbyteBboolean[]bytebooleanbyte

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

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

تعليمات البايت كود

تحتوي JVM على تعليمات للمجموعات التالية من المهام:

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

تعمل هذه التعليمات على مجموعة من القواعد المشتركةأنواع البيانات المجردة بدلاً من أنواع البيانات الأصلية لأي بنية مجموعة تعليمات محددة .

لغات JVM

لغة JVM هي أي لغة ذات وظائف يمكن التعبير عنها من حيث ملف فئة صالح يمكن استضافته بواسطة Java Virtual Machine. يحتوي ملف الفئة على تعليمات Java Virtual Machine ( كود بايت Java ) وجدول رموز، بالإضافة إلى معلومات مساعدة أخرى. تنسيق ملف الفئة هو تنسيق ثنائي مستقل عن الأجهزة ونظام التشغيل يستخدم لتمثيل الفئات والواجهات المترجمة. [7]

هناك العديد من لغات JVM، سواء اللغات القديمة التي تم نقلها إلى JVM أو اللغات الجديدة تمامًا. ربما تكون JRuby و Jython أكثر المنافذ شهرة للغات الموجودة، أي Ruby و Python على التوالي. من بين اللغات الجديدة التي تم إنشاؤها من الصفر لتجميعها إلى Java bytecode، قد تكون Clojure و Groovy و Scala و Kotlin هي الأكثر شهرة. الميزة البارزة في لغات JVM هي أنها متوافقة مع بعضها البعض ، بحيث يمكن استخدام مكتبات Scala مع برامج Java والعكس صحيح. [8]

تطبق Java 7 JVM ميزة JSR 292: دعم اللغات ذات النوع الديناميكي [9] على منصة Java، وهي ميزة جديدة تدعم اللغات ذات النوع الديناميكي في JVM. تم تطوير هذه الميزة ضمن مشروع Da Vinci Machine الذي تتمثل مهمته في توسيع JVM بحيث يدعم لغات أخرى غير Java. [10] [11]

متحقق البايت كود

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

يتحقق JVM من جميع التعليمات البرمجية الثنائية قبل تنفيذها. يتكون هذا التحقق بشكل أساسي من ثلاثة أنواع من الفحوصات:

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

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

يسمح المُتحقق ببعض تسلسلات البايت كود فقط في البرامج الصالحة، على سبيل المثال، يمكن لتعليمة القفز (الفرع) استهداف تعليمة داخل نفس الطريقة فقط . علاوة على ذلك، يضمن المُتحقق أن أي تعليمة معينة تعمل في موقع مكدس ثابت، [12] مما يسمح لمُجمِّع JIT بتحويل عمليات الوصول إلى المكدس إلى عمليات وصول إلى سجل ثابت. ولهذا السبب، فإن كون JVM عبارة عن بنية مكدس لا يعني عقوبة سرعة للمحاكاة على البنيات القائمة على السجل عند استخدام مُجمِّع JIT. في مواجهة بنية JVM التي تم التحقق من صحتها بالكود، لا يوجد فرق بالنسبة لمُجمِّع JIT سواء حصل على سجلات وهمية مسماة أو مواضع مكدس وهمية يجب تخصيصها لسجلات البنية المستهدفة. في الواقع، يجعل التحقق من الكود JVM مختلفًا عن بنية المكدس الكلاسيكية، والتي يكون المحاكاة الفعالة باستخدام مُجمِّع JIT أكثر تعقيدًا ويتم إجراؤها عادةً بواسطة مُفسِّر أبطأ. بالإضافة إلى ذلك، فإن المترجم الذي يستخدمه JVM الافتراضي هو نوع خاص يُعرف باسم مفسر القالب، والذي يترجم البايت كود مباشرةً إلى لغة الآلة الأصلية القائمة على السجلات بدلاً من محاكاة المكدس مثل المترجم النموذجي. [13] في العديد من الجوانب، يمكن اعتبار مفسر HotSpot مُجمِّع JIT بدلاً من مفسر حقيقي، مما يعني أن بنية المكدس التي يستهدفها البايت كود لا تُستخدم فعليًا في التنفيذ، ولكنها مجرد مواصفات للتمثيل الوسيط الذي يمكن تنفيذه جيدًا في بنية قائمة على السجلات. مثال آخر على أن بنية المكدس هي مجرد مواصفات ويتم تنفيذها في آلة افتراضية قائمة على السجلات هو وقت تشغيل اللغة المشتركة . [14]

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

تنفيذ آمن للكود عن بعد

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

لقد تم إثبات صحة محققي البايت كود رسميًا بواسطة صناعة بطاقات Javacard (التطوير الرسمي لمحقق مضمن لبايت كود بطاقة Java [16] )

مُفسِّر البايت كود ومُجمِّع في الوقت المناسب

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

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

لا توجد صلة ضرورية بين لغة برمجة Java وBytecode Java. يمكن تجميع البرنامج المكتوب بلغة Java مباشرة إلى لغة الآلة لجهاز كمبيوتر حقيقي ويمكن تجميع البرامج المكتوبة بلغات أخرى غير Java إلى Bytecode Java.

تم تصميم بايت كود Java ليكون مستقلاً عن النظام الأساسي وآمنًا. [17] لا تتضمن بعض تطبيقات JVM مفسرًا، ولكنها تتكون فقط من مُجمِّع في الوقت المناسب. [18]

JVM في متصفح الويب

في بداية عمر منصة Java، تم تسويق JVM كتقنية ويب لإنشاء تطبيقات ويب غنية . اعتبارًا من عام 2018 ، لا يتم شحن معظم متصفحات الويب وأنظمة التشغيل التي تجمع متصفحات الويب مع مكون إضافي لـ Java ، ولا تسمح بالتحميل الجانبي لأي مكون إضافي غير Flash . تم إيقاف تشغيل مكون إضافي لمتصفح Java في JDK 9. [19]

تم تصميم البرنامج الإضافي لمتصفح Java NPAPI للسماح لـ JVM بتنفيذ ما يسمى بـ Java applets المضمنة في صفحات HTML. بالنسبة للمتصفحات التي تم تثبيت البرنامج الإضافي عليها، يُسمح للبرنامج الصغير بالرسم في منطقة مستطيلة على الصفحة المخصصة له. نظرًا لأن البرنامج الإضافي يتضمن JVM، فإن برامج Java applets ليست مقيدة بلغة برمجة Java؛ يمكن تشغيل أي لغة تستهدف JVM في البرنامج الإضافي. تسمح مجموعة محدودة من واجهات برمجة التطبيقات لبرامج Java applets بالوصول إلى ميكروفون المستخدم أو تسريع 3D، على الرغم من أن برامج Java applets غير قادرة على تعديل الصفحة خارج منطقتها المستطيلة. يعمل Adobe Flash Player ، التكنولوجيا الرئيسية المنافسة، بنفس الطريقة في هذا الصدد.

اعتبارًا من يونيو 2015 ، وفقًا لـ W3Techs، انخفض استخدام Java applet و Silverlight إلى 0.1% لكل منهما لجميع مواقع الويب، بينما انخفض Flash إلى 10.8%. [20]

JVMs ومترجمات JavaScript

منذ مايو 2016، يسمح JavaPoly للمستخدمين باستيراد مكتبات Java غير المعدلة، واستدعائها مباشرة من JavaScript. يسمح JavaPoly لمواقع الويب باستخدام مكتبات Java غير المعدلة، حتى إذا لم يكن لدى المستخدم Java مثبتًا على جهاز الكمبيوتر الخاص به. [21]

الترجمة إلى جافا سكريبت

مع التحسينات المستمرة في سرعة تنفيذ JavaScript، جنبًا إلى جنب مع الاستخدام المتزايد للأجهزة المحمولة التي لا تنفذ متصفحات الويب الخاصة بها دعم المكونات الإضافية، هناك جهود لاستهداف هؤلاء المستخدمين من خلال التحويل إلى JavaScript. من الممكن إما تحويل الكود المصدر أو كود البايت الخاص بـ JVM إلى JavaScript.

يسمح تجميع البايت كود JVM، والذي يعد عالميًا عبر لغات JVM، بالبناء على المترجم الحالي للغة لتحويل البايت كود إلى JavaScript. المترجمون الرئيسيون للبايت كود JVM إلى JavaScript هم TeaVM، [22] والمترجم الموجود في Dragome Web SDK، [23] وBck2Brwsr، [24] وj2js-compiler. [25]

تتضمن أدوات التحويل الرائدة من لغات JVM إلى JavaScript أداة التحويل من Java إلى JavaScript الموجودة في Google Web Toolkit وClojurescript (Clojure) وGrooScript (Apache Groovy) وScala.js (Scala) وغيرها. [26]

انظر أيضا

مراجع

  1. ^ yan (2023-06-24). "JDK 20 Release Notes". Oracle Corporation . مؤرشف من الأصل في 2021-07-09 . تم الاسترجاع 2023-06-24 .
  2. ^ بيل فينيرز، داخل آلة جافا الافتراضية، محفوظ في 2021-01-25 على موقع واي باك مشين، الفصل 5
  3. ^ "برنامج عملية مجتمع Java (SM) - طلبات مواصفات Java - تفاصيل JSR# 924". Jcp.org. مؤرشف من الأصل في 2020-12-24 . تم الاسترجاع في 2015-06-26 .
  4. ^ "برنامج عملية مجتمع Java (SM) - طلبات مواصفات Java - تفاصيل JSR# 202". Jcp.org. مؤرشف من الأصل في 2012-02-26 . تم الاسترجاع في 2015-06-26 .
  5. ^ مواصفات آلة جافا الافتراضية المحفوظة في 2008-07-09 على موقع واي باك مشين (الإصدارات الأولى المحفوظة في 2008-10-12 على موقع واي باك مشين والثانية المحفوظة في 2011-09-25 على موقع واي باك مشين متاحة أيضًا عبر الإنترنت).
  6. ^ "الفصل 2. بنية الآلة الافتراضية Java". مؤرشف من الأصل في 2021-09-15 . تم الاسترجاع 2021-09-15 .
  7. ^ "مواصفات آلة Java الافتراضية: إصدار Java SE 7" (PDF) . Docs.oracle.com. مؤرشف (PDF) من الأصل في 2021-02-04 . تم الاسترجاع في 2015-06-26 .
  8. ^ "الأسئلة الشائعة - قابلية التشغيل البيني لـ Java". scala-lang.org . مؤرشف من الأصل في 2020-08-09 . تم الاسترجاع في 2015-11-18 .
  9. ^ "برنامج عملية مجتمع Java (SM) - طلبات مواصفات Java - تفاصيل JSR# 292". Jcp.org. مؤرشف من الأصل في 2020-12-20 . تم الاسترجاع في 2015-06-26 .
  10. ^ "مشروع آلة دافنشي". Openjdk.java.net. مؤرشف من الأصل في 2020-11-11 . تم الاسترجاع في 2015-06-26 .
  11. ^ "ميزة جديدة في JDK 7: دعم اللغات ذات النوع الديناميكي في آلة Java الافتراضية". Oracle.com. مؤرشف من الأصل في 2018-09-13 . تم الاسترجاع في 2015-06-26 .
  12. ^ "عملية التحقق". مواصفات آلة جافا الافتراضية . صن مايكروسيستمز. 1999. مؤرشف من الأصل في 2011-03-21 . تم استرجاعه في 2009-05-31 .
  13. ^ "نظرة عامة على وقت تشغيل HotSpot - المترجم". OpenJDK . مؤرشف من الأصل في 2022-05-21 . تم الاسترجاع في 2021-05-24 .
  14. ^ "لماذا لا نجعل CLR قائمًا على السجل؟ · العدد #4775 · dotnet/runtime". GitHub . مؤرشف من الأصل في 2023-04-20 . تم الاسترجاع في 2021-05-24 .
  15. ^ Freund, Stephen N.; Mitchell, John C. (1999). "A formal framework for the Java bytecode language and verifier". Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, language, and applications - OOPSLA '99 . ص. 147–166. CiteSeerX 10.1.1.2.4663 . doi :10.1145/320384.320397. ISBN  978-1581132380. S2CID  14302964.
  16. ^ Casset, Ludovic; Burdy, Lilian; Requet, Antoine (10 April 2002). "Formal Development of an Embedded Verifier for Java Card Byte Code" (PDF) . Inria - المعهد الوطني للأبحاث في العلوم والتكنولوجيا الرقمية في جامعة كوت دازور . مؤرشف من الأصل (PDF) في 3 أكتوبر 2022.
  17. ^ David J. Eck, Introduction to Programming Using Java Archived 2014-10-11 at the Wayback Machine , Seventh Edition, Version 7.0, August 2014 at Section 1.3 "The Java Virtual Machine"
  18. ^ مقدمة Oracle JRockit أرشيف 2015-09-06 على موقع Wayback Machine الإصدار R28 في 2. "فهم التجميع والتحسين في الوقت المناسب"
  19. ^ "Oracle deprecates the Java browser plugin, preparings for its demise". Ars Technica . 28 يناير 2016. مؤرشف من الأصل في 8 أبريل 2016 . تم الاسترجاع في 15 أبريل 2016 .
  20. ^ "الاتجاهات السنوية التاريخية في استخدام لغات البرمجة من جانب العميل، يونيو 2015". W3techs.com . تم الاسترجاع في 2015-06-26 .
  21. ^ Krill, Paul (13 May 2016). "JavaPoly.js imports existing Java code and invokes it direct from JavaScript". InfoWorld . مؤرشف من الأصل في 25 يوليو 2016 . تم الاسترجاع 18 يوليو 2016 .
  22. ^ "الصفحة الرئيسية لمشروع TeaVM". Teavm.org. مؤرشف من الأصل في 2015-06-27 . تم الاسترجاع في 2015-06-26 .
  23. ^ "Dragome Web SDK". Dragome.com. مؤرشف من الأصل في 2015-08-01 . تم الاسترجاع في 2015-06-26 .
  24. ^ "Bck2Brwsr - APIDesign". Wiki.apidesign.org. مؤرشف من الأصل في 2015-06-27 . تم الاسترجاع في 2015-06-26 .
  25. ^ Wolfgang Kuehn (decatur). j2js-compiler محفوظ في 2013-09-29 على موقع Wayback Machine GitHub
  26. ^ "قائمة اللغات التي يتم تجميعها إلى JS · jashkenas/coffeescript Wiki · GitHub". Github.com. 2015-06-19. مؤرشف من الأصل في 2020-01-31 . تم الاسترجاع في 2015-06-26 .
  • تتضمن التوضيحات والتعديلات على مواصفات Java Virtual Machine، الإصدار الثاني المؤرشف بتاريخ 2006-01-10 على موقع Wayback Machine قائمة بالتغييرات التي يجب إجراؤها لدعم J2SE 5.0 وJSR 45
  • JSR 45 تم أرشفته في 2006-02-05 على موقع Wayback Machine ، يحدد التغييرات التي تطرأ على تنسيق ملف الفئة لدعم تصحيح أخطاء مستوى المصدر للغات مثل JavaServer Pages (JSP) و SQLJ التي يتم ترجمتها إلى Java
Retrieved from "https://en.wikipedia.org/w/index.php?title=Java_virtual_machine&oldid=1243042627"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate