Ulasan modern tentang Java [ditutup]

Saya telah pemrograman selama beberapa tahun dan saya mulai di Jawa, dan pada waktu saya saya telah menemukan banyak sumber yang berbeda mengklaim Jawa sebagai bahasa yang lebih rendah dalam beberapa cara. Saya sadar betul bahwa setiap bahasa memiliki kelebihan dan kekurangan, tetapi banyak hal yang saya baca tentang Java tampaknya sudah ketinggalan zaman.

Alasan yang paling sering dikutip untuk Java lebih rendah adalah bahwa ia jauh lebih lambat daripada bahasa yang dikompilasi secara native lainnya, seperti C ++ misalnya. Banyak orang mengkritik perancang permainan Notch (yang mengembangkan Minecraft) karena menggunakan Java karena kekurangannya di departemen kinerja. Saya tahu Java jauh lebih lambat saat itu, tetapi ada banyak perbaikan sejak itu, terutama kompilasi JIT.

Saya ingin mendapatkan beberapa pendapat objektif tentang Jawa sebagai bahasa saat ini. Jadi pertanyaan saya ada 4 bagian.

1. Performa.

   Sebuah. Bagaimana kecepatan Java saat ini dibandingkan dengan C ++?

   b. Apakah mungkin untuk membuat judul AAA modern menggunakan Java?

   c. Di area apa secara spesifik Java lebih lambat dari C ++, jika sama sekali? (Yaitu Angka-angka, grafik, atau hanya sekitar)

2. Apakah Java sekarang dianggap sebagai bahasa yang dikompilasi atau bahasa yang ditafsirkan?

3. Apa saja kekurangan utama Jawa yang telah diatasi sejak awal?

4. Apa saja kekurangan utama di Jawa yang belum ditangani?

Sunting:

Hanya untuk tujuan klarifikasi saya tidak membuat Java vs C ++ ini, jelas rata-rata c ++ akan sedikit lebih cepat daripada Java. Saya hanya perlu sesuatu untuk membandingkan Jawa dalam hal kedewasaan sebagai bahasa pada saat ini. Karena c ++ telah ada selamanya, saya pikir saya akan menjadi titik perbandingan yang bagus.

Sebuah. Bagaimana kecepatan Java saat ini dibandingkan dengan C ++?

Sulit diukur. Perlu dicatat bahwa sebagian besar kecepatan implementasi, itu adalah pengalokasi memori, adalah algoritma yang sangat berbeda di Jawa dan C ++. Sifat kolektor yang non-deterministik membuatnya sangat sulit untuk mendapatkan data kinerja yang bermakna dibandingkan dengan manajemen memori deterministik C ++, karena Anda tidak pernah dapat memastikan keadaan kolektor saat ini. Ini berarti bahwa sangat sulit untuk menulis benchmark yang mungkin membandingkan mereka secara bermakna. Beberapa pola alokasi memori berjalan lebih cepat dengan GC, beberapa menjalankan lebih cepat dengan pengalokasi asli.

Apa yang akan saya katakan adalah, Java GC harus berjalan cepat dalam setiap situasi. Namun, pengalokasi asli dapat diganti dengan yang lebih sesuai. Saya baru-baru ini mengajukan pertanyaan pada SO tentang mengapa C # Dictionarybisa dieksekusi di (0,45 ms di komputer saya) dibandingkan dengan yang setarastd::unordered_mapyang dieksekusi pada (10 ms di mesin saya). Namun, dengan hanya mengganti pengalokasi dan hasher untuk yang lebih tepat, saya memotong waktu eksekusi menjadi 0,34 ms pada mesin saya - sepertiga puluh dari run-time asli. Anda tidak akan pernah bisa berharap untuk melakukan optimasi khusus semacam itu dengan Java. Contoh yang sangat baik di mana ini dapat membuat perbedaan nyata adalah threading. Pustaka thread asli seperti TBB menyediakan pengalokasi caching thread yang jauh lebih cepat daripada pengalokasi tradisional ketika berhadapan dengan banyak alokasi pada banyak thread.

Sekarang, banyak orang akan berbicara tentang peningkatan JIT dan bagaimana JIT memiliki informasi lebih lanjut. Tentu itu benar. Tapi itu masih bahkan tidak jauh dari apa yang dapat ditarik oleh kompiler C ++ - karena kompiler memiliki, secara komparatif, waktu dan ruang tak terbatas untuk menjalankan, dari perspektif run-time dari program akhir. Setiap siklus dan setiap byte yang dihabiskan JIT untuk memikirkan cara terbaik untuk mengoptimalkan program Anda adalah siklus dimana program Anda tidak menghabiskan mengeksekusi dan tidak dapat digunakan untuk kebutuhan memori itu sendiri.

Selain itu, akan selalu ada saat-saat di mana optimisasi kompiler dan JIT tidak dapat membuktikan optimisasi tertentu - terutama dalam hal-hal seperti melarikan diri analisis. Dalam C ++, kemudian sebagai nilai pada stack pula , compiler tidak perlu melakukan itu. Selain itu, ada hal-hal sederhana, seperti memori yang berdekatan. Jika Anda mengalokasikan array di C ++, maka Anda mengalokasikan satu array yang berdekatan. Jika Anda mengalokasikan array di Java, maka itu tidak bersebelahan sama sekali, karena array hanya diisi dengan pointer yang bisa menunjuk ke mana saja. Ini bukan hanya memori dan overhead waktu untuk tipuan ganda, tetapi overhead cache juga. Hal semacam ini adalah di mana semantik bahasa Jawa hanya menegakkan bahwa itu harus lebih lambat daripada kode C ++ yang setara.

Pada akhirnya, pengalaman pribadi saya adalah bahwa Java dapat sekitar setengah kecepatan C ++, rata-rata. Namun, secara realistis tidak ada cara untuk mendukung pernyataan kinerja apa pun tanpa rangkaian tolok ukur yang sangat komprehensif, karena algoritme yang berbeda secara mendasar.

b. Apakah mungkin untuk membuat judul AAA modern menggunakan Java?

Saya berasumsi bahwa maksud Anda "permainan", di sini, dan bukan kesempatan. Pertama, Anda harus menulis semuanya sendiri dari awal karena hampir semua perpustakaan dan infrastruktur yang ada menargetkan C ++. Meskipun tidak membuat hal itu mustahil, hal itu tentu saja dapat memberikan kontribusi yang kuat terhadap yang tidak mungkin. Kedua, bahkan mesin C ++ hampir tidak dapat memenuhi batasan memori kecil dari konsol yang ada - jika JVM bahkan ada untuk konsol tersebut - dan gamer PC mengharapkan sedikit lebih banyak untuk memori mereka. Membuat game AAA berkinerja cukup sulit di C ++, saya tidak melihat bagaimana itu bisa dicapai di Jawa. Tidak ada yang pernah menulis game AAA dengan waktu yang signifikan dihabiskan dalam bahasa yang tidak dikompilasi. Lebih dari itu, itu hanya akan sangat rawan kesalahan. Penghancuran deterministik sangat penting ketika berhadapan dengan, misalnya, sumber daya GPU- dan di Jawa, Anda

c. Di area apa secara spesifik Java lebih lambat dari C ++, jika sama sekali? (Yaitu Angka-angka, grafik, atau hanya sekitar)

Saya pasti akan pergi untuk semua. Sifat referensi yang dipaksakan dari semua objek Java berarti bahwa Java memiliki tipuan yang jauh lebih banyak dan referensi di dalamnya daripada C ++ tidak - contoh yang saya berikan sebelumnya dengan array, tetapi juga berlaku untuk semua objek anggota, misalnya. Ketika kompiler C ++ dapat mencari variabel anggota dalam waktu konstan, Java run-time harus mengikuti pointer lain. Semakin banyak akses yang Anda lakukan, semakin lambat ini akan didapat, dan tidak ada yang bisa dilakukan JIT tentang itu.

Di mana C ++ dapat membebaskan dan menggunakan kembali sepotong memori hampir secara instan, di Jawa Anda harus menunggu koleksi, dan saya berharap potongan itu tidak keluar dari cache, dan secara inheren membutuhkan lebih banyak memori berarti cache lebih rendah dan kinerja paging. Kemudian lihat semantik untuk hal-hal seperti tinju dan unboxing. Di Jawa, jika Anda ingin referensi int, Anda harus mengalokasikannya secara dinamis. Itu pemborosan yang melekat dibandingkan dengan semantik C ++.

Maka Anda memiliki masalah generik. Di Jawa, Anda hanya bisa beroperasi pada objek generik melalui run-time inheritance. Di C ++, templat benar-benar nol overhead - sesuatu yang tidak cocok dengan Java. Ini berarti bahwa semua kode generik di Jawa secara inheren lebih lambat daripada setara generik dalam C ++.

Dan kemudian Anda datang ke Perilaku Tidak Terdefinisi. Semua orang membencinya ketika program mereka memamerkan UB, dan semua orang berharap itu tidak ada. Namun, UB pada dasarnya memungkinkan optimalisasi yang tidak pernah ada di Jawa. Lihatlah postingan ini yang menjelaskan optimisasi berdasarkan UB. Tidak mendefinisikan perilaku berarti bahwa implementasi dapat melakukan lebih banyak optimasi dan mengurangi kode yang diperlukan untuk memeriksa kondisi yang tidak terdefinisi dalam C ++ tetapi didefinisikan dalam Java.

Pada dasarnya, semantik Java menyatakan bahwa itu adalah bahasa yang lebih lambat daripada C ++.

Apakah Java sekarang dianggap sebagai bahasa yang dikompilasi atau bahasa yang ditafsirkan?

Itu tidak benar-benar cocok dengan salah satu dari kelompok-kelompok itu. Saya akan mengatakan bahwa dikelola benar-benar merupakan kategori yang terpisah pada dirinya sendiri, meskipun saya akan mengatakan itu pasti lebih seperti bahasa yang ditafsirkan daripada bahasa yang dikompilasi. Lebih penting lagi, hanya ada dua sistem yang dikelola utama, JVM dan CLR, dan ketika Anda mengatakan "dikelola" itu cukup eksplisit.

Apa saja kekurangan utama Jawa yang telah diatasi sejak awal?

Tinju otomatis dan unboxing adalah satu-satunya hal yang saya ketahui. Obat generik memecahkan beberapa masalah, tetapi jauh dari banyak.

Apa saja kekurangan utama di Jawa yang belum ditangani?

Obat generik mereka sangat, sangat lemah. Obat generik C # jauh lebih kuat - walaupun tentu saja, tidak ada yang cukup templat. Kehancuran deterministik adalah kekurangan besar lainnya. Segala bentuk lambda / closure juga merupakan masalah utama - Anda bisa melupakan API fungsional di Jawa. Dan, tentu saja, selalu ada masalah kinerja, untuk bidang-bidang yang membutuhkannya.

Saya akan mulai dengan ketentuan bahwa hampir tidak mungkin bagi siapa pun untuk memberikan pendapat yang benar-benar netral tentang bahasa pemrograman. Jika Anda tahu dua bahasa dengan cukup baik untuk mengomentarinya dengan penuh arti, hampir tidak dapat dihindari bahwa Anda akan lebih suka satu daripada yang lain. Sebagai peringatan yang adil, saya lebih suka C ++ daripada Java, yang tidak diragukan lagi mempengaruhi komentar saya setidaknya sampai tingkat tertentu.

1a. Kecepatan: kecepatan yang Anda dapatkan dari C ++ atau Java umumnya akan lebih sedikit bergantung pada bahasa atau implementasinya daripada keterampilan programmer yang menggunakannya. Pada akhirnya, C ++ mungkin bisa menang untuk kecepatan lebih sering daripada tidak, tetapi perbedaan dalam kode yang Anda tulis adalah yang paling penting.
1b. Ya mungkin. Pada saat yang sama, C ++ sudah mapan, dan saya ragu kebanyakan studio game melihat cukup banyak keuntungan untuk beralih ke Java.
1c. Jawaban menyeluruh untuk ini mungkin bisa mengisi volume yang besar. C ++ umumnya akan lebih baik dengan sumber daya yang lebih terbatas. Java diuntungkan lebih dari (misalnya) memiliki banyak "cadangan" memori yang tersedia.
2. Eksekusi lambat dan pengumpulan sampah lambat mungkin adalah dua yang paling jelas. Perpustakaan windowing awal (AWT) cukup canggung - Swing adalah peningkatan besar.
3. Verbositas. Kurangnya kelebihan operator. Penggunaan pengumpulan sampah. Kurangnya pewarisan berganda. Java Generics sangat terbatas dibandingkan dengan template C ++.

Saya harus menambahkan bahwa beberapa (semua?) Kerugian itu (terutama penggunaan pengumpulan sampah, tetapi yang lain juga) dipandang oleh banyak orang sebagai keuntungan Jawa. Satu-satunya pengecualian yang mungkin adalah verbositasnya. Situasi verbositas sedikit demi sedikit membaik, tetapi Anda tentu tidak terlalu sering melihat kontes golf kode Java, dan dalam kode biasa cenderung menggunakan banyak kode juga. Saya menduga setidaknya ada beberapa orang yang melihatnya lebih mudah dibaca dan dimengerti, sehingga mungkin bisa dilihat sebagai keuntungan juga.

1. Mengenai kinerja;
   1. Dalam kecepatan eksekusi kode murni, Java hampir sama dengan C ++ langsung. Tetapi Java cenderung menggunakan lebih banyak memori - sebagian karena berbasis GC, sebagian karena desainnya lebih fokus pada kesederhanaan dan keamanan daripada efisiensi. Karena masalah cache, lebih banyak memori diterjemahkan ke kecepatan yang lebih rendah. Sebuah banyak lebih rendah bila dibandingkan dengan sangat-tuned C ++.
   2. Jika Anda menganggap bahwa judul AAA harus bekerja di tepi apa yang mungkin menggunakan perangkat keras saat ini, tidak. Setidaknya tidak di sisi klien. Saya berani bertaruh bahwa beberapa judul AAA sudah menggunakan Java untuk bagian dari infrastruktur backend.
   3. Di mana pun Anda bekerja dengan kumpulan data besar dan C ++ dapat dioptimalkan untuk mengaksesnya dengan cara yang ramah-cache.
2. Ini dikompilasi untuk bytecode dan JIT-dikompilasi pada saat runtime. Dikompilasi vs. Diartikan adalah dikotomi yang salah dan ketinggalan zaman.
3. & 4. Ada terlalu banyak hal untuk dicantumkan semuanya, dan akan ada ketidaksepakatan pada sebagian besar dari mereka.

Pertama beberapa konteks, C ++ saya sangat berkarat, jadi sebagian besar pengalaman saya dengan Java berhubungan dengan pengalaman saya yang lebih baru dengan C #, yang merupakan perbandingan apel lebih banyak untuk apel.

1. Kecepatan

Sebuah. Bagaimana kecepatan Java saat ini dibandingkan dengan C ++?

Saya pikir ini yang terbaik dijawab oleh pertanyaan SO Mengapa java memiliki reputasi lambat? tapi saya juga berpikir seluruh pertanyaan ini diwarnai oleh posting blog Jeff Atwood, Gorilla vs. Shark . ^{Terima kasih untuk Péter & Christopher.}

b. Apakah mungkin untuk membuat judul AAA modern menggunakan Java?

Itu tergantung pada prioritas pengembang dan keterampilan pengembang. Ditambah lagi, ini bukan salah satu atau situasi, bagian-bagian berbeda dari judul mungkin memerlukan hal-hal berbeda dari bahasa tempat mereka diimplementasikan, yang mengarah ke lingkungan bahasa yang heterogen.

Saya telah melihat sejumlah permainan baru-baru ini menyebutkan bahwa mereka memuat lingkungan Python saat mereka memuat dan saya menduga bahwa kuda untuk kursus adalah motivasi yang kuat jika Anda ingin mendapatkan gelar Anda tepat waktu untuk musim liburan (misalnya) .

c. Di area apa secara spesifik Java lebih lambat dari C ++, jika sama sekali? (Yaitu Angka-angka, grafik, atau hanya sekitar)

Anda dapat menulis kode yang berkinerja buruk dalam bahasa apa pun, tetapi beberapa bahasa membuatnya lebih mudah untuk membuat pilihan yang baik, sementara yang lain lebih cenderung membiarkan diri Anda di- hoist oleh petard Anda sendiri . Java termasuk dalam kategori sebelumnya, C ++ jelas jatuh ke dalam kategori yang terakhir.

Dengan kekuatan besar datang tanggung jawab besar seperti yang mereka katakan (belum lagi kemampuan untuk benar-benar mengacaukan tumpukan Anda * 8 ').

2. Apakah Java sekarang dianggap sebagai bahasa yang dikompilasi atau bahasa yang ditafsirkan?

Saya tidak bisa mengatakan apa yang oleh kebanyakan orang dianggap, tetapi banyak orang tahu perbedaan antara bahasa yang dikompilasi dan ditafsirkan, dan tidak pernah tinggal di gua selama 20 tahun terakhir, juga akan tahu bahwa JIT ( Just-in -Time ) compiler adalah bagian penting dari ekosistem Java, jadi kemungkinan besar akan dipertimbangkan untuk dikompilasi hari ini.

3. Apa saja kekurangan utama Jawa yang telah diatasi sejak awal?

Saya seorang mualaf yang cukup baru ke Jawa, jadi saya memiliki sedikit konteks tentang bagaimana ia telah berevolusi. Tetapi menarik untuk dicatat bahwa ada buku-buku seperti Jawa: The Good Parts yang berusaha mengarahkan orang ke arah bagian-bagian bahasa yang harus lebih disukai hari ini dan menjauhkan orang dari daerah-daerah yang, atau seharusnya, usang.

4. Apa saja kekurangan utama Jawa yang belum ditangani?

Menurut saya, satu masalah dengan Java adalah lambatnya adopsi fitur-fitur baru.

Setelah datang ke Jawa dari C #, dan melihat melalui halaman perbandingan Wikipedia , ini adalah hal-hal yang menonjol bagi saya:

Hal yang saya lewatkan di Jawa, dibandingkan dengan C #

• Properti , terutama properti otomatis. Mereka membuat membangun dan memelihara antarmuka menjadi lebih mudah.
• Penutupan / lambdas . Saya benar-benar kecewa ketika saya mendengar bahwa dukungan Java sedang mendorong kembali lagi . ^{Akhirnya kami memiliki Penutupan / lambdas di Jawa 8, tetapi waktu yang dibutuhkan membuktikan pernyataan saya tentang adopsi yang lambat.}
• Ketik inferensi ( var) mungkin tampak seperti gula sintaksis, tetapi ketika Anda memiliki jenis generik yang kompleks, itu dapat membuat kode lebih jelas dengan menghapus banyak duplikasi yang tidak berharga.
• Kelas parsial sangat membantu untuk menjaga kode yang dihasilkan secara otomatis (katakanlah dari pembangun GUI) terpisah dari kode tertulis programmer.
• Jenis nilai , kadang-kadang ada argumen untuk menggunakan ringan di structatas kelas penuh.
• Metode ekstensi dapat membuat sistem menjadi kompleks jika digunakan berlebihan, tetapi sangat bagus untuk menunjukkan cara kanonik dalam mengimplementasikan sesuatu untuk suatu kelas jika diperlukan.
• Jenis yang tidak ditandatangani , terkadang bit ekstra itu dapat membuat perbedaan. * 8 ')

Hal yang tidak saya lewatkan di Jawa, dibandingkan dengan C #

• Operator overloading besar bila digunakan dengan benar, tetapi ketika digunakan buruk dapat mengakibatkan sulit untuk menemukan bug dan keterputusan antara apa operator harus jelas lakukan dan apa yang sebenarnya dilakukannya.
• Jenis nilai nullable sepertinya selalu menyebabkan lebih banyak masalah daripada nilainya.
• Akses ke unsafekode. Anda harus sangat berhati-hati dengan hal ini sehingga saya jarang menganggapnya sepadan dengan usaha ekstra.

Karena itu, bahkan ketika membandingkan apel dengan apel, Jawa dianggap tertinggal.

Dua masalah besar lainnya yang saya lihat dengan Java adalah keterlambatan start-up yang mengerikan dan fakta bahwa (untuk beberapa JVM) Anda harus mengatur tumpukan mikro Anda dan bahkan tumpukan generasi permanen . Dengan aplikasi C # selalu dimulai segera dan saya tidak pernah sekalipun berpikir tentang heap, karena itu dialokasikan keluar dari kolam memori sistem, bukan dari kolam yang dialokasikan sebelumnya ditugaskan ke mesin virtual.

Saya dapat menunjukkan Anda sumber yang dapat membantu menjawab bagian pertama dari pertanyaan Anda untuk Anda. Bahasa pemrograman menembak http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php adalah sumber yang cukup bagus untuk melihat seberapa cepat bahasa dibandingkan satu sama lain. Mereka bahkan dapat disaring pada kategori yang berbeda untuk melihat di mana bahasa daerah melakukan lebih baik daripada yang lain di. Jawa jauh lebih cepat daripada beberapa tahun yang lalu.

1) Berbicara tentang UX yang saya dapatkan dengan Java, rasanya lambat. Saya tidak bisa memberi tahu Anda mengapa sebenarnya. Saya belum menemukan aplikasi desktop berbasis Java, yang tidak terasa lambat dan memiliki alternatif non-Java yang lebih cepat. Yang sedang berkata, Java bisa sangat cepat dalam kecepatan komputasi murni dan internet penuh dengan tolok ukur untuk membuktikan itu. Namun waktu boot aplikasi Java dan responsif GUI mereka belum meningkatkan IMHO. Mungkin Anda bisa melakukannya;)
Pada akhirnya, kecepatan bukanlah masalah besar. Tidak hanya perangkat keras yang semakin cepat dan cepat, tetapi juga bahwa kebanyakan orang secara mengejutkan hanya sedikit peduli selama perangkat lunak melakukannya, apa yang harus dilakukan dan rasio waktu yang dihabiskan untuk berinteraksi vs waktu yang dihabiskan untuk menunggu adalah masuk akal.

2) Perbedaan ini menjadi sangat buram akhir-akhir ini, yang benar-benar ada nilainya.

3 + 4) Sebenarnya ada beberapa perubahan pada Java. Beberapa orang sudah berargumen, bahwa perubahan-perubahan ini telah menodai filosofi Jawa yang sangat sederhana dengan mengikat fitur-fitur asing. Sangat sulit untuk mengatakan secara objektif, apa kekurangan itu, dan apa kekuatannya. Bagi saya, Java tidak perlu verbose, restriktif dan miskin dalam fitur, sementara orang lain menganggap sifat-sifat ini sebagai ketidakjelasan, keamanan dan kejelasan yang menyenangkan.
Jadi walaupun hal-hal ini, yang secara pribadi membuat saya tidak menggunakan Java, saya tidak berpikir hanya menambahkan hal-hal yang saya lewatkan di Jawa adalah ide yang bagus. Ada banyak bahasa yang saya suka jalankan di JVM dan membengkokkan Java agar lebih dekat dengan mereka hanya akan mengalahkan tujuan Java.

Ini masalah preferensi

Masalahnya dengan Java, itu dirancang untuk mencegah Anda menembak diri sendiri. Suatu alasan yang mulia, tetapi dengan segala batasan yang diikatnya pada Anda, bukan tidak mungkin, bahwa Anda tersandung salah satu kaki aman Anda, tidak dapat menguatkan diri Anda dengan tangan terikat di belakang Anda untuk keselamatan Anda sendiri dan akhirnya mati, karena kamu mematahkan tengkorakmu. : D
Di satu sisi, Jawa adalah respons terhadap C ++, yang memberi Anda cukup banyak tali untuk tidak hanya menggantung diri, tetapi juga seluruh dunia. Itu semua tali itu, yang membuatnya sangat menarik bagi para koboi. Semua kebebasan itu dan semua kekuatan itu.

Jadi sederhananya, ini benar-benar hanya masalah preferensi.

Tapi, intinya adalah, dengan C ++ sebagai alternatif untuk Java, Anda bebas memilih batasan Anda sendiri. Atau benar-benar menjadi gila dengan semua kontrol yang Anda miliki, berisiko untuk benar-benar membingungkan rekan-rekan Anda:

Saya melihat `cout 'digeser" Hello world "kali ke kiri dan berhenti di sana.
- Steve Gonedes

Java memilih untuk tidak menawarkan kelebihan operator, karena alasan itulah. Tentu saja ini mencegah orang dari mengaburkan kode mereka dengan mengalikan fungsi pointer dengan daftar. Tetapi pada saat yang sama mencegah orang lain untuk melakukan perhitungan geometris / aljabar dengan operator yang biasa. (v1 * v2 / scale) + (v3 * m)benar-benar jauh lebih jelas daripada v1.multiply(v2).divide(scale).add(v3.multiply(m)). Saya mengerti mengapa ini dapat menunda orang yang berurusan dengan grafik dan perhitungan 3d.

Java memilih untuk memaksakan pengumpulan sampah, sedangkan di C ++ Anda dapat memilih. Anda benar-benar dapat menggali sampai ke bawah dan mendekati perangkat keras. Anda dapat mengemas data secara padat ke dalam struct. Anda dapat melakukan sihir gelap, seperti root kuadrat terbalik cepat . Anda dapat melakukan beberapa program pemrograman yang paling rumit dan samar di bumi menggunakan templat. Tapi itu juga berarti, Anda bisa tersesat dan menghabiskan berjam-jam men-debug semua kekacauan yang Anda buat atau mencari kesalahan kompiler yang benar-benar tidak membantu.
Tetapi jika Anda memiliki disiplin untuk hanya menggunakan bagian-bagian dari bahasa yang benar-benar Anda kuasai, Anda dapat menulis kode C ++ sama amannya dengan kode Java, tetapi Anda memiliki opsi untuk secara bertahap mendorong maju.

Jadi, sementara tidak ada yang secara teknis mencegah Anda dari menulis perangkat lunak terdepan dengan Java, Anda akan menemukan bahwa banyak pengembang benar-benar bersemangat untuk menulis perangkat lunak yang hebat dan bersenang-senang dan berkembang sambil melakukannya bergerak melampaui apa yang ditawarkan Java sebagai bahasa.

Tetapi dunia tidak hanya terdiri dari orang-orang yang ditetapkan untuk menciptakan hal besar berikutnya atau hanya orang-orang yang akan membatasi penggunaan kekuatan yang diberikan kepada mereka hanya sejauh mereka mengendalikannya. IMHO Java adalah pasangan yang cocok untuk orang-orang yang ingin menghasilkan hasil yang stabil dengan cara yang nyaman.

Pengumpulan sampah adalah hal besar. Sering kali, GC akan mengunci segala sesuatu yang lain selama beberapa ratus milidetik (tergantung pada ukuran tumpukan), dan melakukan koleksi besar. Ini bagus jika Anda tidak memiliki kendala waktu, tetapi jika terlambat berarti kegagalan, ini adalah penghenti acara. Anda dapat menghabiskan uang untuk Java waktu nyata, dan OS waktu nyata, tetapi Anda cukup menggunakan GCC dan Linux standar dan Anda tidak akan mengalami masalah ini.

Tanpa jeda acak yang tidak dapat diprediksi, Java mungkin cukup cepat untuk sebagian besar hal hari ini. Dan jika Anda menghabiskan waktu berbulan-bulan untuk mengubah pengaturan GC Anda dan semacamnya, mungkin, mungkin saja, Anda bisa membuatnya bekerja cukup lama sehingga pelanggan dapat memotong cek Anda.

3) Kekurangan yang diperbaiki.

Beberapa tahun yang lalu ada banyak kemarahan di Jawa. Kebanyakan programmer Java adalah programmer web / server dan mereka menjadi marah dengan verbositas Java. Jadi beberapa bahasa seperti Ruby menjadi populer dan Java mulai berkurang. Namun, dengan anotasi dan kerangka kerja baru seperti hibernate dan Spring, orang-orang berhenti mengeluh dan kembali ke Jawa.

4) Kekurangan saat ini

Perangkat kerasnya semuanya multicore. Meskipun Java dapat melakukan multithread, ini didasarkan pada C yang merupakan bahasa berurutan dan fungsi untuk membuatnya multithread tidak elegan, untuk sedikitnya. By the way, itu bukan hanya kritik terhadap Jawa, tetapi cukup banyak dari semua bahasa. Diperlukan cara berpikir yang sangat berbeda tentang kode. Mungkin pemrograman fungsional adalah jalan masa depan.

Saya agak bereaksi terhadap pertanyaan ini karena akan memberikan jawaban yang menyesatkan dan sebagian besar tidak relevan:

b. Apakah mungkin untuk membuat judul AAA modern menggunakan Java?

Semua orang bisa setuju bahwa judul AAA akan sulit diproduksi menggunakan Java dan tidak ada contoh aktual yang saya sadari. Namun mengingat sifat AAA yang akan mengasumsikan banyak hal (karena itu benar-benar istilah yang membingungkan dari pemasaran), jadi lebih baik untuk bertanya sebagai berikut:

Apakah mungkin membuat judul modern dengan keberhasilan yang masuk akal menggunakan Java?

Jawabannya adalah " Ya, Anda bisa. " Namun, bagian kesuksesan yang sebenarnya dari persamaan ini lebih didasarkan pada ketekunan dan keberuntungan Anda (atau kepatuhan terhadap zeitgeist) tetapi itu berada di luar cakupan situs ini.

Area kecepatan tertentu turun ke compiler vs compiler. Bukan bahasa vs bahasa. Mungkin ada keuntungan untuk kompilasi JIT karena dapat mengoptimalkan untuk spesifikasi mesin yang sedang berjalan. Bandingkan JIT yang dikompilasi C ++ vs Java untuk perbandingan kompiler "apel dengan apel" yang lebih banyak.

Tetapi ada beberapa hal di mana bahasa Jawa sendiri membatasi kinerjanya sendiri.

1. alokasi pada tumpukan. Java tidak bisa melakukan ini. Untuk kelas ukuran kecil tetap dalam solusi non-rekursif ini sering ideal. Anda juga dapat menghindari tumpukan fragmentasi.

2. fungsi bukan virtual. Java tidak bisa melakukan ini. Semua panggilan metode menerima hit permanen bahkan ketika mereka tidak direncanakan untuk diganti.

Mungkin beberapa hal lain, tetapi hanya itu yang bisa saya pikirkan dari atas kepala saya.

1) tidak relevan, dan argumentatif untuk boot.
Tidak hanya perangkat lunak utama yang dapat dibuat di Jawa, sistem seperti itu dikirimkan setiap hari dan menjalankan sebagian besar perusahaan besar di dunia saat ini.
2) lagi.
Baca spesifikasi JVM dan Anda tahu. Jawa tidak pernah menjadi bahasa yang ditafsirkan.
3) lagi.
Baca 15 tahun catatan rilis. Mustahil bagi kami untuk mencari tahu apa yang Anda anggap sebagai "kelemahan utama" untuk diatasi.
4) lagi.
Kelemahan utama yang harus diatasi adalah JCP yang cenderung ikut campur dengan bahasa inti dan perpustakaan tanpa alasan jelas selain untuk mendapatkan nama somoene pada JSR sehingga mereka dapat menulis buku dengan uraian otoritatif bahwa "mereka adalah pemimpin JSR-666 ". Semoga restrukturisasi Oracle atas JCP akan membereskannya.
Anda tampaknya hanya ingin membangkitkan perang bahasa di sini, dan membuat prasangka Anda terhadap Jawa dikonfirmasi oleh orang lain karena Anda tidak dapat menemukan pembenaran nyata untuk itu sendiri.