خوب دقیقا همونطوری که دوستمون blackhalo فرمودن، قبلا تمام بایت کدها توسط ماشین مجازی باید تفسیر میشد، ولی این دلیل نمیشه که بگیم قبلا هم زبان جاوا مفسری بوده کلا. بهرحال کدهای ما توسط javac به بایت کد کامپایل میشدن، پس همون موقع هم مرحله اول که تبدیل سورس کد به بایت کد بوده و توسط javac انجام می شده، کامپایلری بوده و بعد مرحله بارگذاری کلاس ها توی ماشین مجازی و اجرای برنامه توسط JRE، تفسیری.
بعد از اینکه دیدن این کار باعث کندی اجرای برنامه های جاوا شده، اومدن رو یه پروژه به اسم HotSpot کار کردن که یک ماشین مجازی جدید برای جاوا بود که از تکنیک کامپایل (JIT ( Just In Time برای بایت کدها بهره می بره. جالبه که بدونید از نسخه ی ۱/۳ جاوا ماشین مجازی پیش فرض جاوا شد همین HotSpot و کاملا به زبان ++C نوشته شده
نسخه ی JRE عرضه توسط شرکت Oracle دو ورژن متفاوت داره، نسخه ی کلاینت و نسخه ی سرور. نسخه ی کلاینت به کلی از شیوه ی تفسیر بایت کدها استفاده می کنه یعنی همون روش قدیمی. ولی نسخه ی سرور از تکنیک های JIT برای کامپایل بایت کدها استفاده می کنه. البته نه همه ی بابت کدها، بلکه از شمارنده استفاده می کنه که ببینه یه کد خاص چند بار مورد استفاده قرار می گیره، اگر از مقدار سطح آستانه ای که پیش فرض در نظر می گیره بالاتر بود اون رو کامپایل می کنه ( در تایید و تکمیل فرمایشات جناب blackhalo )
اما در مورد Binding توی جاوا
مجبوریم با مثال پیش بریم
کد:
class A
{
public void foo()
{
System.out.println("I am print method in Class A");
}
}
class B extends A
{
public void foo()
{
System.out.println("I am print method in Class B");
}
}
public class C
{
public static void main(String [] args)
{
A a=new A();
B b=new B();
a.foo();
b.foo();
A ref=null;
ref=b;
ref.foo();
یه کد خیلی ساده. خوب مسلما تو فراخوانی اولین و دومین متد، جاوا به نظر می رسه که داره از early binding استفاده می کنه
اما این تصمیم مسلما برمی گرده به اینکه، توی سلسله مراتب ارث بری جاوا چه رفتاری از خودش نشون میده، اونجا می تونیم تصمیم بگیریم
و می بینیم تو اجرای کد ()ref.foo جاوا پیغام کلاس فرزند رو چاپ می کنه نه کلاس والد رو. این مثال نقض، نشون میده یا آقای مقسمی اشتباه کردن تو پاسخشون یا طراح سوال کنکور!