Instalasi Pelaksanaan Java Game Adalah Mimpi Buruk

Anda akrab sahih dengan Java Game , barangkali lebih akrab dibandingkan maksud lain dari komputer mengapa ada istilah debug , atau ada penyesuaian percepatan hardware . Sehingga terkadang ada anekdot, mereka nan menyalakan komputernya buat segera menyerbu Java Games ialah mereka nan menganggap komputer itu semacam kulkas loka makanan siap saji tinggal di makan.

Karena Java Game mudah, tinggal instal tinggal main, dan peraturan games-nya tak komplek dibandingkan dengan games lainnya nan berbasis pada teknologi selain Java. Game ternama seperti Feeding Frenzy, Plant vs Zombie, atau Angry Birds, dibuat dalam pola bahasa pemerogaman Java dari Sun Microsystem.

Java game juga sukses menghidupkan kembali game tahun 80-an, nan dapat Anda mainkan dalam majemuk fasilitas. Penulis paling menyukai fasilitas Netcafe. Bersama dengan baku Java, Netcafe sukses menghidupkan kembali games console pada era 80-an, seperti Super Mario, Contra, Bomberman, Pooyan, Chip's n Dale, Battle city dan lainnya. Lantas, apa dan bagaimana sebenarnya Java Game itu?

Java buat pemrograman java game syahdan memiliki banyak laba nan dapat disebutkan. Misalnya kerangka berpikir berorientasi objek nan elegan, dukungan cross-platform , penggunaan kode feedback dengan segala kemudahan pengembangan, kehandalan alat, ketersediaan dan stabilitas.

Keuntungan lainnya, yakni dokumentasi nan baik, dukungan dari Sun Microsystems, rendah biaya pengembangan, kemampuan buat menggunakan kode warisan (misalnya C, C + +), dan meningkatkan produktivitas programmer (Excel 2006).

Sebagian kritikus game Java cenderung melewatkan berbagai laba itu dan lebih memilih buat berkonsentrasi pada kritik kekurangan dari java game, di antaranya sebagai berikut.

1. Java terlalu lambat buat pemrograman game;
2. Java memiliki kebocoran memori;
3. Java terlalu high end;
4. Instalasi pelaksanaan Java ialah mimpi buruk;
5. Java tak didukung formatnya pada game konsol terbaru;
6. Tidak ada nan menggunakan Java buat menulis langsung dari games;
7. Sun Microsystems tak tertarik dalam mendukung Java game.

Hampir semua keberatan secara substansial dapat dipertanyakan balik. Bahasa Java kira-kira memiliki kecepatan nan sama seperti C + +. Kebocoran memori bisa dihindari dengan pemrograman nan baik dan teknik seperti profiling. Ya, benar, Java ialah high end , tapi juga menawarkan lebih banyak akses langsung ke hardware grafis dan perangkat eksternal lainnya.

Instalasi bukan mimpi buruk, jika Anda menggunakan software instalasi nan layak. Ada dan semakin banyak Java game nan sangat baik dan menyenangkan. Dan pula sejumlah besar dukungan pada Java Game tersedia dari Sun, lihat saja situs resminya.

Titik generik tentang keberatan-keberatan ini ialah bahwa mereka memiliki alasan validitas nan mengacu pada akhir 1990-an, ketika bahasa dan library pemrogaman kurang canggih dan lebih lambat.

Pada 1990 ialah waktu nan lama dan telah berlalu bagi para pengguna dan komunitas pengembang Java, sebab saat ini pun mereka, para pengembang java game sedang berkembang lebih pesat menghindari kekhawatiran, menghasilkan sejumlah besar tools, donasi online, dan contoh kode nan berguna.

Sekarang, kembali ke kritik. Java lebih lambat dibandingkan dengan C dan C + +, bahasa nan dominan buat pemrograman games saat ini. Argumen ini berlaku ketika Java pertama kali muncul (JDK sekitar 1996), tetapi telah menjadi semakin konyol dengan setiap rilis baru.

Beberapa tokoh bolehlah meletakkan JDK 1.0, versi pertama sebagai bahasa pemrogaman nan 20 hingga 40 kali lebih lambat dari C + +. Namun, J2SE 5-arus-release biasanya hanya 1,1 kali lebih lambat. Banyak benchmark menunjukkan bahwa Java SE 6 ialah sekitar 20% lebih cepat dari J2SE 5.

Kecepatan up di Java sebagian besar sebab pemugaran dalam desain compiler. Teknologi Hotspot diperkenalkan pada J2SE 1,3 memungkinkan sistem run-time buat mengidentifikasi daerah krusial dari kode nan digunakan berkali-kali, dan ini dikompilasi agresif.

Teknologi Hotspot sendiri nisbi baru, dan itu sangat menjelaskan bahwa versi masa depan Java akan menghasilkan kecepatan up lebih lanjut. Misalnya, J2SE 5.0 dengan kecepatan 1,2 hingga 1,5 kali lebih cepat dari pendahulunya (versi 1.4). Walau demikian teknologi Hotspot memiliki imbas samping disayangkan bahwa aplikasi program ini sering memperlambat di awalan sampai kode telah dianalisis dan dikompilasi.

Ayunan sering diserang sebab lambat. Ayunkan komponen GUI diciptakan dan dikendalikan dari Java, dengan dukungan OS kecil; ini meningkatkan portabilitas mereka dan membuat mereka lebih terkendali dari dalam program Java.

Kecepatan diduga dikompromikan sebab Java memaksakan lapisan tambahan pengolahan di atas suatu OS. Inilah salah satu alasan mengapa beberapa pelaksanaan game masih memanfaatkan Windowing Toolkit (AWT)-itu sebagian besar hanya metode pembungkus sederhana sekitar panggilan OS.

Bahkan, jika Swing lambat, games java tak memerlukan GUI kompleks; layar penuh bermain game dengan kontrol mouse dan keyboard ialah norma. Elemen GUI dikelola oleh Swing, seperti bar menu, tombol, dan bidang teks, nan tak diperlukan, sementara mouse dan pengolahan keyboard ditangani oleh AWT. Versi terbaru dari Java menawarkan modus layar penuh sangat efisien dengan menangguhkan lingkungan windowing normal.

Sebuah titik krusial tentang kecepatan ialah mengetahui d imana meletakkan, dan menyalahkan suati kinerja ketika sebuah program berjalan lambat. Biasanya, sebagian besar dari rendering grafis dari game ditangani oleh perangkat keras atau perangkat lunak di luar Java Game.

Sebagai contoh, Java 3D melewati tugas rendernya ke OpenGL atau DirectX, nan bisa meniru kemampuan perangkat keras seperti pemetaan bump. Seringkali kendala kinerja dalam jaringan game ialah sebab jaringan, bukan sebab bahasa Java.

Java mengalami kebocoran memori? Ketika C / C + + programmer mendapati kebocoran memori di Java game, sering kali berarti bahwa mereka tak mengerti bagaimana cara Java bekerja. Java tak menawarkan aritmatika pointer, dan C-gaya khas nan menghasilkan kebocoran memori-seperti terjadinya out-of-boundaries pada array, nan aksesnya ditahan oleh compiler Java.

Namun, programmer bisa mengartikan bahwa progam nan tak lagi dibutuhkan jangan sampai seperti sampah nan dikumpulkan. Ini menjadi masalah jika program ini terus menciptakan objek baru membutuhkan lebih banyak memori dan akhirnya crash ketika alokasi memori maksimum telah terlampaui.

Masalah seperti ini ialah konsekuensi dari gaya pemrograman buruk, sebab pengumpul sampah hanya program bisa melakukan tugasnya ketika suatu objek benar-benar dereferenced , nan berarti program tersebut tak lagi merujuk pada objek.

Gunakanlah alat profiling nan baik, seperti JProfiler bisa sangat membantu dalam mengidentifikasi kode serta mengetahui penggunaan jumlah nan hiperbola dari memori. JProfiler ialah produk komersial, banyak profiler open source tercatat di java-source.net Java SE 6 dilengkapi dengan profiler grafis besar, itu.

Keluhan lain nan berhubungan dengan memori ialah bahwa garbage collector Java mengeksekusi interval nan salah waktu, menyebabkan pelaksanaan menghentikan buat sementara menyapu dan membersihkan nan terkolekt.

JVM dilengkapi dengan beberapa kolektor sampah nan berbeda, nan mengumpulkan berbagai cara, dan bisa dipilih dan fine-tuned dari baris perintah. Informasi tentang kinerja kolektor dipilih bisa dikumpulkan dan dianalisis, dan Java SE 6 menawarkan banyak alat bantu buat tugas-tugas ini, termasuk jps, jstat, jhat, dan jstack.

Titik generik nan disepakati di sini ialah bahwa pengguna perlu menjadi pakar Java buat menginstal dan menjalankan pelaksanaan Java, sedangkan pemain Java game paling hanya ingin bermain saja, dan menjalankan fungsi Java Game hingga maksimal. Instalasi program pelaksanaan Java Games bukan nightmare jika petunjuknya Anda ikuti jelas, semisal code lisence dan sejenisnya. Atau lebih gampang lagi, meminta donasi insal java game, pada mereka nan sudah berhasil menginstalnya, dan itu banyak.