رقابت کلاسیک جاوا و ++ C

البته او معتقد است توانایی جاوا نیازی به تبلیغ ندارد و امروزه به‌همین دلیل است که بسیاری از برنامه‌نویسان از جاوا به‌عنوان بستر اصلی توسعه نرم‌افزاری خود استفاده می‌کنند. هر چند ++C نیز قابلیت‌هایی دارد که جاوا از آن برخوردار نبوده و به‌همین علت در بسترهای مختلف آن را به جاوا ترجیح می‌دهند.

همان‌طور که می‌دانیم، اوراکل در اوایل سال 2010 میلادی سان مایکروسیستمز را خرید و به‌همین علت، نرم‌افزار جاوا هم‌اکنون بخشی از این شرکت به‌حساب می‌آید. با وجود این، پردی سخنان خود را به جاوا و ++C محدود نکرد و معتقد بود با وجود حرکت جدید در توسعه نرم‌افزار (که HTML5 و جاوااسکریپت خود به یک بستر برنامه‌نویسی جدید تبدیل شده‌ است) بسترهای جدید می‌تواند همانند جاوا در سال 1996 قاعده بازی را تغییر دهد. جاوا مزیت‌های زیادی نسبت به ++C دارد و در مقابل، مزیت‌های ++C نسبت به جاوا را بررسی خواهیم کرد.

گفتنی است پردی مسئول توسعه بستر Java EE، JDBC، WebLogic، GlassFish، Coherence، TopLink، iPlanet و Oracle Traffic Director است. پیش از اوراکل، او بنیانگذار شرکت Tangosol بود که اوراکل سال 2007 آن را خرید. پردی از سال 1994 با ++C کار کرده و از سال 1996 روی جاوا سوئیچ کرده است. وی از سال 1999 به جاواEE و بعد در سال 2001، #C را هم آزموده است؛ از این رو دانش خوبی برای مقایسه این زبان‌ها با یکدیگر دارد.

جاوا را با گاربج‌کالکشن آن می‌شناسند. گاربج کالکشن (که به‌معنای جمع‌آوری آشغال است) نوعی مدیریت حافظه خودکار است. گاربج‌کالکتور به‌دنبال جمع‌آوری آشغال یا همان حافظه است که توسط آبجکت‌های بی‌استفاده در برنامه اشغال شده است. بخش عمده‌ای از کدهای ++C به مدیریت حافظه اختصاص داده می‌شود. مدیریت چندمولفه‌ای حافظه در ++C وجود ندارد. ساختن کتابخانه‌ها و کامپوننت‌ها سخت‌تر است و آی‌پی‌های کمتری برای ++C نوشته شده است. گاربج‌کالکشن به‌معنی سرعت بیشتر در اجرای پروژه و میزان باگ‌های کمتر است.

++C در مقایسه با جاوا پیچیده و کند است. توسعه‌دهندگان اعلام کرده‌اند که یک بیلد کامل در ++C می‌تواند 20 ساعت وقت ببرد، در حالی که همین بیلد در جاوا حدود هفت دقیقه وقت خواهد برد. ++C برای دیباگ‌کردن به یک بیلد دیگر نیاز دارد، در حالی‌که جاوا ابزارهایی همچون Ant و Maven دارد که مفیدتر است. البته ناگفته نماند که ابزارهای Make و NMake در ++C هم همین کار را انجام می‌دهد، اما به اندازه رقبایشان مفید نیست.

++C کد منبع را به دو بخش هدر و فایل‌ها تقسیم می‌کند. به‌همین دلیل به نظارت شدید نیاز دارد که فایل‌های hpp و cpp را بررسی کند. با ++C، یک کد در چند محل قرار می‌گیرد، برخی هدرها به‌صورت inline درون فایل cpp جا می‌گیرد و برخی دیگر در هدرها. آرتیفکت‌ها نیز بسته به کامپایلر تغییر می‌کنند. با وجود این، جاوا تنها دو نوع فرمت دارد: java. و class.

جاوا استانداردهای باینری خاص خودش را دارد. علاوه بر این‌که می‌تواند توسط JVM به‌عنوان یک کلاس بارگذاری شود، فایل کلاس آن نیز می‌تواند کامپایل شود. ++C هیچ استاندارد باینری‌ ندارد و هدرهای از پیش کامپایل شده ‍ ++C مخصوص به یک کامپایلر و یک بستر است. ++C همچنین نیاز به میزان زیادی از دیتا دارد که بتواند برای کامپایل‌های چند بستره استفاده شود. جاوا امور مرتبط با یک بستر خاص را به زمان اجرا واگذار می‌کند.

راه استانداردی برای لینک کردن دینامیک کلاس‌ها در زبان ++C وجود ندارد. جاوا می‌تواند تعداد دلخواهی از کلاس‌ها را به‌عنوان یک پکیج کنار هم قرار داده و هنگام نیاز به‌صورت دینامیک بارگذاری و لینک کند. لینک‌های دینامیک جاوا با شکست روبه‌رو نمی‌شود. این اتفاق در ++C به جهنم DLL معروف است.

جاوا انواع خاص دارد، همچنین کتابخانه درونی مخصوص و پرتابل دارد، از I/O، شبکه‌ها، XML/HTML و ارتباط دیتابیس‌ها به‌طور پیش‌فرض پشتیبانی می‌کند. ++C به‌طور پیش‌فرض هیچ‌یک از این کارها را انجام نمی‌دهد.

بازتاب عملی است که برنامه می‌تواند ساختار و رفتار (منظور مقادیر، متادیتا، ویژگی‌ها و توابع است) یک آبجکت را در زمان اجرا بررسی و اصلاح کند. جاوا قابلیت‌های کامل بازتاب را پیاده کرده است. ++C البته اطلاعات خاص زمان اجرا را می‌دهد (RTTI)، اما قابلیت بازتاب ندارد. بازتاب می‌تواند درک درستی از فعالیت‌های فریم‌ورک‌ها ایجاد کند و رفتار یک برنامه را بدون دسترسی به کد و از طریق آبجکت آن شناسایی کند.

هر چند بازدهی یکی از قابلیت‌های جاوا به‌شمار نمی‌رود و بسیاری ++C را سریع‌تر از جاوا می‌دانند، پردی معتقد است گاربج کالکشن باعث می‌شود مدیریت حافظه بسیار بهینه‌تر شود و از این رو روی بازدهی تاثیر مستقیم بگذارد. جاوا از طرف دیگر از چندنخی پشتیبانی می‌کند، در حالی که ++C حامی چند نخی نیست. اسمارت پوینترهای ++C سه‌برابر از رفرنس‌های جاوا کندتر است. جاوا همچنین درون JVM خود، سیستم کامپایل JIT (در لحظه) را پیاده‌سازی کرده است که بازدهی بهتری داشته باشد.

جاوا از پوینترها استفاده نمی‌کند، به‌همین ترتیب دسترسی دلخواه به حافظه و نابودی پروسس در این عملیات ممکن نخواهد بود. همچنین در جاوا سرریز بافر رخ نمی‌دهد و کد و داده نمی‌تواند به‌طور تصادفی با یکدیگر قاطی شود. همچنین جاوا رویه چک کردن مرزها را در خود دارد. چک کردن مرزها باعث می‌شود متغیر پیش از ذخیره‌سازی بررسی شود و اگر اندازه‌اش از ظرفش بزرگ‌تر بود، از این کار جلوگیری شود تا دیگر داده‌ها را خراب نکند.

جاوا برای پروسس‌های سریع و کوتاه مناسب نیست. گراف کلاس‌های اولیه که باید لود شود، بسیار بزرگ است و هر بار که JVM اجرا می‌شود، کد به‌اصطلاح JIT ‌شده یا از اول تفسیر می‌شود.

جاوا از نظر حجم حافظه، بسیار سنگین‌تر از ++C است. این تفاوت بویژه در نرم‌افزارهای کوچک‌تر بیشتر خودش را نشان می‌دهد. نیاز به حافظه بیشتر باعث شده تا جاوا نتواند روی برخی دستگاه‌ها کار کند.

دیر یا زود، این مشکل رخ می‌دهد که گاربج‌کالکتور به‌طور دائم در پس‌زمینه اجرا نمی‌شود و نیاز بیشتری به پردازنده دارد. از این رو هنگام اجرای برنامه، هالت‌های موقت رخ می‌دهد و پردازش همزمان با کمک این زبان ممکن نخواهد نبود. این مشکل در سیستم‌های توزیع شده به یک کابوس تبدیل می‌شود. هر چند اگر میزان حافظه بیشتر باشد، این مشکل کمتر به چشم خواهد خورد.

++C به نابودی قطعی مجهز است، اما جاوا خیر. نابودی قطعی برای مدیریت منابع بسیار مفید است. در ++C وقتی آبجکت‌ها حذف می‌شود، نابودکننده‌هایشان فورا اجرا و منابع سیستم درست بعد از نابودی یک آبجکت آزاد می‌شود.

سیستم‌های عامل بر مبنای ++C/ C نوشته شده‌ است. آی‌پی‌ها معمولا با C کار می‌کند و رابط‌های کاربری و دیگر قابلیت‌های سطح سیستم‌عامل معمولا به فراخوانی‌های C نیازمند است. جاوا در نقطه مقابل، تنها از یک رابط اصلی استفاده می‌کند که باید برای ارتباط با آن از جاوا استفاده کرد.