رقابت كلاسيك جاوا و ++ C

 

در كنفرانس QCon نيويورك، كامرون پردي، معاون توسعه نرم‌افزاري گروه سرورهاي اوراكل صحبت‌هاي خود را با معرفي فضاي فعلي به‌عنوان ميوه‌اي رسيده و در خدمت توسعه‌دهندگان نرم‌افزاري آغاز كرد. او توفان فعلي موبايل، رايانش ابري و HTML5 را در تعامل كامل با يكديگر خواند و عنوان كرد همزماني اين رويدادها جابه‌جايي بزرگي در دنياي توسعه نرم‌افزار به‌وجود آورده است. در اين گفت‌وگو، پردي از نقش زبان‌هاي برنامه‌نويسي در شكل‌دهي صنعت نرم‌افزار صحبت كرد. به‌عنوان مثال، وي گفت برخلاف اين كه برخي مي‌انديشند جاوا از همه نظر بر ++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 (در لحظه) را پياده‌سازي كرده است كه بازدهي بهتري داشته باشد.

امنيت

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

كمبودهاي جاوا نسبت به ++C

جاوا هيچ وقت نتوانست به‌طور كامل جايگزين ++C شود، چرا كه نسبت به اين زبان معايبي دارد كه قابل چشم‌پوشي نيست. از جمله اين معايب مي‌توان به موارد زير اشاره كرد:

زمان اجرا

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

ميزان حافظه درخواستي

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

توقف كامل گاربج‌كالكشن

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

عدم نابودي قطعي

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

موانع بر سر راه يكپارچگي

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





تاريخ : چهار شنبه 21 تير 1391برچسب:, | | نویسنده : مقدم |