Apa gunanya mengubah kode sumber ke bytecode Java?


37

Jika seseorang membutuhkan JVM yang berbeda untuk arsitektur yang berbeda, saya tidak bisa mencari tahu apa logika di balik memperkenalkan konsep ini. Dalam bahasa lain kita membutuhkan kompiler yang berbeda untuk mesin yang berbeda, tetapi di Jawa kita membutuhkan JVM yang berbeda jadi apa logika di balik memperkenalkan konsep JVM atau langkah tambahan ini ??


1
agas

12
@gnat: Sebenarnya, itu bukan duplikat. Ini adalah "kode sumber vs byte", yaitu hanya transformasi pertama. Dalam istilah bahasa, ini Javascript versus Jawa; tautan Anda adalah C ++ versus Java.
MSalters

2
Apakah Anda lebih suka menulis bytecode interpreter sederhana untuk 50 model alat yang Anda tambahkan kode digital untuk peningkatan atau 50 kompiler untuk 50 perangkat keras yang berbeda. Java pada awalnya dikembangkan untuk peralatan dan mesin. Itu setelan kuatnya. Ingatlah bahwa ketika membaca jawaban-jawaban ini sebagai java tidak memiliki keuntungan nyata saat ini (karena ketidakefisienan proses penafsiran). Itu hanya model yang terus kami gunakan.
The Great Duck

1
Anda tampaknya tidak mengerti apa mesin virtual adalah . Ini sebuah mesin. Itu bisa diimplementasikan dalam perangkat keras dengan kompiler kode asli (dan dalam kasus JVM sudah). Bagian 'virtual' adalah yang penting di sini: Anda pada dasarnya meniru arsitektur itu di atas yang lain. Katakanlah saya menulis emulator 8088 untuk dijalankan pada x86. Anda tidak akan mem-porting kode 8088 lama ke x86, Anda hanya akan menjalankannya di platform yang ditiru. JVM adalah mesin yang Anda targetkan seperti yang lain, perbedaannya beroperasi di atas platform lain.
Jared Smith

7
@TheGreatDuck proses Menafsirkan? Kebanyakan JVM saat ini melakukan kompilasi tepat waktu dengan kode mesin. Belum lagi bahwa "interpretasi" adalah istilah yang cukup luas saat ini. CPU itu sendiri hanya "menafsirkan" kode x86 ke dalam mikrokode internalnya sendiri, dan itu digunakan untuk meningkatkan efisiensi. Intel CPU terbaru juga sangat cocok untuk penerjemah (walaupun tentu saja Anda akan menemukan tolok ukur untuk membuktikan apa pun yang ingin Anda buktikan).
Luaan

Jawaban:


79

Logikanya adalah bahwa bytecode JVM jauh lebih sederhana daripada kode sumber Java.

Kompiler dapat dianggap, pada tingkat yang sangat abstrak, memiliki tiga bagian dasar: penguraian, analisis semantik, dan pembuatan kode.

Parsing terdiri dari membaca kode dan mengubahnya menjadi representasi pohon di dalam memori kompiler. Analisis semantik adalah bagian di mana ia menganalisis pohon ini, mencari tahu apa artinya, dan menyederhanakan semua konstruksi tingkat tinggi ke tingkat yang lebih rendah. Dan pembuatan kode mengambil pohon yang disederhanakan dan menulisnya menjadi output datar.

Dengan file bytecode, fase parsing sangat disederhanakan, karena ditulis dalam format stream byte datar yang sama dengan yang digunakan JIT, daripada bahasa sumber rekursif (terstruktur pohon). Juga, banyak pengangkatan berat dari analisis semantik telah dilakukan oleh kompiler Java (atau bahasa lain). Jadi yang harus dilakukan adalah stream-membaca kode, melakukan parsing minimal dan analisis semantik minimal, dan kemudian melakukan pembuatan kode.

Ini membuat tugas yang JIT lakukan jauh lebih sederhana, dan karena itu jauh lebih cepat untuk dieksekusi, sambil tetap mempertahankan metadata tingkat tinggi dan informasi semantik yang memungkinkan untuk secara teoritis menulis kode sumber tunggal, kode lintas platform.


7
Beberapa upaya awal lainnya pada distribusi applet, seperti SafeTCL, benar-benar mendistribusikan kode sumber. Penggunaan bytecode Java yang sederhana dan ditentukan secara spesifik membuat verifikasi program jauh lebih mudah ditelusuri, dan itu adalah masalah sulit yang sedang dipecahkan. Bytecode seperti p-code sudah dikenal sebagai bagian dari solusi untuk masalah portabilitas (dan ANDF mungkin sedang dalam pengembangan saat itu).
Toby Speight

9
Tepat. Waktu mulai Java sudah menjadi sedikit masalah karena bytecode -> langkah kode mesin. Jalankan javac pada proyek Anda (non-sepele), dan kemudian bayangkan melakukan seluruh kode mesin Java -> pada setiap start up.
Paul Draper

24
Ini memiliki satu manfaat besar lainnya: jika suatu hari kita semua ingin beralih ke bahasa baru yang hipotetis - sebut saja "Scala" - kita hanya perlu menulis satu Scala -> kompiler bytecode, daripada lusinan Scala -> kode mesin kompiler. Sebagai bonus, kami mendapatkan semua optimasi platform spesifik JVM secara gratis.
BlueRaja - Danny Pflughoeft

8
Beberapa hal masih tidak mungkin dalam kode byte JVM, seperti optimasi panggilan ekor. Saya ingat ini sangat kompromi bahasa fungsional yang mengkompilasi ke JVM.
JDługosz

8
@ JDługosz benar: JVM sayangnya memberlakukan beberapa batasan / idiom desain yang, walaupun mungkin wajar jika Anda berasal dari bahasa imperatif, dapat menjadi penghalang buatan jika Anda ingin menulis kompiler untuk bahasa yang bekerja secara fundamental. berbeda. Dengan demikian saya menganggap LLVM sebagai target yang lebih baik, sejauh menyangkut penggunaan kembali pekerjaan bahasa di masa depan - ia memiliki keterbatasan juga, tetapi mereka kurang lebih sesuai dengan keterbatasan yang dimiliki prosesor saat ini (dan kemungkinan beberapa waktu di masa depan).
leftaroundabout

27

Representasi menengah dari berbagai jenis semakin umum dalam desain kompiler / runtime, karena beberapa alasan.

Dalam kasus Java, alasan nomor satu pada awalnya kemungkinan adalah portabilitas : Java pada awalnya dipasarkan secara besar-besaran sebagai "Write Once, Run Anywhere". Meskipun Anda dapat mencapai ini dengan mendistribusikan kode sumber dan menggunakan kompiler yang berbeda untuk menargetkan platform yang berbeda, ini memiliki beberapa kelemahan:

  • kompiler adalah alat kompleks yang harus memahami semua sintaks kenyamanan bahasa; bytecode bisa menjadi bahasa yang lebih sederhana, karena lebih dekat ke kode yang dapat dieksekusi mesin daripada sumber yang bisa dibaca manusia; ini berarti:
    • kompilasi mungkin lambat dibandingkan dengan mengeksekusi bytecode
    • kompiler yang menargetkan platform yang berbeda mungkin menghasilkan perilaku yang berbeda, atau tidak mengikuti perubahan bahasa
    • memproduksi kompiler untuk platform baru jauh lebih sulit daripada memproduksi VM (atau bytecode-to-native compiler) untuk platform itu
  • mendistribusikan kode sumber tidak selalu diinginkan; bytecode menawarkan beberapa perlindungan terhadap rekayasa balik (meskipun masih cukup mudah untuk mendekompilasi kecuali sengaja dikaburkan)

Keuntungan lain dari representasi perantara meliputi:

  • optimisasi , di mana pola dapat dilihat dalam bytecode dan dikompilasi menjadi setara lebih cepat, atau bahkan dioptimalkan untuk kasus-kasus khusus saat program berjalan (menggunakan "JIT", atau "Just In Time", kompiler)
  • interoperabilitas antara beberapa bahasa dalam VM yang sama; ini telah menjadi populer dengan JVM (misalnya Scala), dan merupakan tujuan eksplisit dari kerangka .net

1
Java juga berorientasi pada sistem yang diembed. Dalam sistem seperti itu, perangkat keras memiliki beberapa kendala memori dan CPU.
Laiv

Dapatkah compliers dikembangkan dengan cara yang pertama kali mereka mengkompilasi kode sumber Java ke dalam kode byte dan kemudian mengkompilasi kode byte ke dalam kode mesin? Apakah itu menghilangkan sebagian besar kerugian yang Anda sebutkan?
Sher10ck

@ Sher10ck Ya, sangat mungkin AFAIK untuk menulis kompiler yang secara statis mengubah bytecode JVM ke instruksi mesin untuk arsitektur tertentu. Tapi itu hanya masuk akal jika itu meningkatkan kinerja yang cukup untuk lebih besar daripada upaya ekstra untuk distributor, atau waktu ekstra untuk penggunaan pertama bagi pengguna. Sistem tertanam dengan daya rendah mungkin menguntungkan; PC modern yang mengunduh dan menjalankan banyak program yang berbeda mungkin akan lebih baik dengan JIT yang telah disesuaikan. Saya pikir Android pergi ke suatu tempat ke arah ini, tetapi tidak tahu detailnya.
IMSoP

8

Sepertinya Anda bertanya-tanya mengapa kami tidak hanya mendistribusikan kode sumber. Biarkan saya membalikkan pertanyaan itu: mengapa kita tidak mendistribusikan kode mesin saja?

Jelas jawabannya di sini adalah bahwa Java, dengan desain, tidak menganggapnya tahu mesin apa yang akan dijalankan oleh kode Anda; itu bisa berupa desktop, komputer super, telepon, atau apa pun di antaranya. Java menyisakan ruang untuk kompiler JVM lokal untuk melakukan hal itu. Selain meningkatkan portabilitas kode Anda, ini memiliki manfaat yang bagus untuk memungkinkan kompiler melakukan hal-hal seperti memanfaatkan optimasi spesifik mesin, jika ada, atau masih menghasilkan setidaknya kode kerja jika tidak. Hal-hal seperti instruksi SSE atau akselerasi perangkat keras hanya dapat digunakan pada mesin yang mendukungnya.

Dilihat dari sudut ini, alasan untuk menggunakan kode byte lebih dari kode sumber mentah lebih jelas. Semakin sedekat mungkin dengan bahasa mesin mentah memungkinkan kita untuk menyadari atau sebagian menyadari beberapa manfaat dari kode mesin, seperti:

  • Waktu startup lebih cepat, karena beberapa kompilasi dan analisis sudah dilakukan.
  • Keamanan, karena format byte-code memiliki mekanisme built-in untuk menandatangani file distribusi (sumber bisa melakukan ini dengan konvensi, tetapi mekanisme untuk mencapai ini tidak built-in seperti halnya dengan kode byte).

Perhatikan bahwa saya tidak menyebutkan eksekusi yang lebih cepat. Kode sumber dan kode byte keduanya atau (secara teori) dapat dikompilasi sepenuhnya ke kode mesin yang sama untuk eksekusi aktual.

Selain itu, kode byte memungkinkan untuk beberapa perbaikan dibandingkan kode mesin. Tentu saja ada kemandirian platform dan optimasi perangkat keras yang saya sebutkan sebelumnya, tetapi ada juga hal-hal seperti melayani kompiler JVM untuk menghasilkan jalur eksekusi baru dari kode lama. Ini bisa untuk menambal masalah keamanan, atau jika optimasi baru ditemukan, atau untuk mengambil keuntungan dari instruksi perangkat keras baru. Dalam praktiknya jarang terjadi perubahan besar seperti ini, karena dapat mengekspos bug, tetapi itu mungkin, dan itu adalah sesuatu yang terjadi dengan cara kecil sepanjang waktu.


8

Tampaknya ada setidaknya dua pertanyaan berbeda di sini. Salah satunya adalah tentang kompiler secara umum, dengan Java pada dasarnya hanya contoh dari genre. Yang lain lebih spesifik ke Jawa kode byte spesifik yang digunakannya.

Kompiler pada umumnya

Pertama-tama mari kita perhatikan pertanyaan umum: mengapa kompiler menggunakan beberapa representasi perantara dalam proses mengkompilasi kode sumber untuk dijalankan pada beberapa prosesor tertentu?

Pengurangan Kompleksitas

Satu jawaban untuk itu cukup sederhana: itu mengubah masalah O (N * M) menjadi masalah O (N + M).

Jika kita diberi bahasa sumber N, dan target M, dan setiap kompiler sepenuhnya independen, maka kita membutuhkan kompiler N * M untuk menerjemahkan semua bahasa sumber ke semua target tersebut (di mana "target" adalah sesuatu seperti kombinasi dari sebuah prosesor dan OS).

Namun, jika semua kompiler setuju pada representasi perantara umum, maka kita dapat memiliki ujung depan kompilator N yang menerjemahkan bahasa sumber ke representasi perantara, dan ujung kompilator M yang menerjemahkan representasi perantara ke sesuatu yang cocok untuk target tertentu.

Segmentasi Masalah

Lebih baik lagi, ini memisahkan masalah menjadi dua domain eksklusif lebih atau kurang. Orang yang tahu / peduli tentang desain bahasa, penguraian dan hal-hal seperti itu dapat berkonsentrasi pada ujung depan kompiler, sedangkan orang yang tahu tentang set instruksi, desain prosesor, dan hal-hal seperti itu dapat berkonsentrasi pada bagian belakang.

Jadi, misalnya, mengingat sesuatu seperti LLVM, kami memiliki banyak ujung depan untuk berbagai bahasa yang berbeda. Kami juga memiliki back-end untuk banyak prosesor yang berbeda. Seorang pria bahasa dapat menulis front-end baru untuk bahasanya, dan dengan cepat mendukung banyak target. Seorang pria prosesor dapat menulis back-end baru untuk targetnya tanpa berurusan dengan desain bahasa, penguraian, dll.

Memisahkan kompiler menjadi ujung depan dan ujung belakang, dengan representasi perantara untuk berkomunikasi antara keduanya tidak asli dengan Java. Sudah praktik yang cukup umum untuk waktu yang lama (sejak jauh sebelum Jawa datang, toh).

Model Distribusi

Sejauh Java menambahkan sesuatu yang baru dalam hal ini, itu dalam model distribusi. Secara khusus, meskipun kompiler telah dipisahkan menjadi bagian ujung depan dan ujung belakang secara internal untuk waktu yang lama, mereka biasanya didistribusikan sebagai produk tunggal. Misalnya, jika Anda membeli kompiler Microsoft C, secara internal ia memiliki "C1" dan "C2", yang merupakan front-end dan back-end - tetapi apa yang Anda beli hanyalah "Microsoft C" yang mencakup keduanya potongan (dengan "driver kompiler" yang mengoordinasikan operasi antara keduanya). Meskipun kompiler dibangun dalam dua bagian, untuk pengembang normal yang menggunakan kompiler itu hanya satu hal yang diterjemahkan dari kode sumber ke kode objek, dengan tidak ada yang terlihat di antaranya.

Java, sebaliknya, mendistribusikan front-end dalam Java Development Kit, dan back-end di Java Virtual Machine. Setiap pengguna Java memiliki back-end kompiler untuk menargetkan sistem apa pun yang ia gunakan. Pengembang Java mendistribusikan kode dalam format perantara, jadi ketika pengguna memuatnya, JVM melakukan apa pun yang diperlukan untuk menjalankannya pada mesin khusus mereka.

Preseden

Perhatikan bahwa model distribusi ini juga tidak sepenuhnya baru. Sebagai contoh, sistem-P UCSD bekerja dengan cara yang sama: ujung-ujung depan kompiler menghasilkan kode-P, dan setiap salinan sistem-P menyertakan mesin virtual yang melakukan apa yang diperlukan untuk mengeksekusi kode-P pada target tertentu 1 .

Kode byte Java

Kode byte Java sangat mirip dengan kode-P. Ini pada dasarnya instruksi untuk mesin yang cukup sederhana. Mesin itu dimaksudkan sebagai abstraksi dari mesin yang ada, sehingga cukup mudah untuk menerjemahkan dengan cepat ke hampir semua target spesifik. Kemudahan terjemahan adalah penting sejak awal karena maksud aslinya adalah untuk menafsirkan kode byte, seperti yang telah dilakukan P-System (dan, ya, itulah cara implementasi awal bekerja).

Kekuatan

Kode byte Java mudah untuk dihasilkan oleh front-end kompiler. Jika (misalnya) Anda memiliki pohon yang cukup khas mewakili ekspresi, biasanya cukup mudah untuk melintasi pohon, dan menghasilkan kode secara langsung dari apa yang Anda temukan di setiap node.

Kode byte Java cukup kompak - dalam banyak kasus, jauh lebih kompak daripada kode sumber atau kode mesin untuk prosesor yang paling khas (dan, terutama untuk sebagian besar prosesor RISC, seperti SPARC yang dijual Sun ketika mereka mendesain Java). Ini sangat penting pada saat itu, karena salah satu tujuan utama Java adalah untuk mendukung applet - kode yang tertanam di halaman web yang akan diunduh sebelum eksekusi - pada saat kebanyakan orang mengakses kami melalui modem melalui saluran telepon di sekitar 28,8 kilobit per detik (meskipun, tentu saja, masih ada beberapa orang yang menggunakan modem yang lebih tua dan lebih lambat).

Kelemahan

Kelemahan utama dari kode byte Java adalah bahwa mereka tidak terlalu ekspresif. Meskipun mereka dapat mengekspresikan konsep yang ada di Jawa dengan cukup baik, mereka tidak bekerja dengan baik untuk mengekspresikan konsep yang bukan bagian dari Jawa. Demikian juga, walaupun mudah untuk mengeksekusi kode byte pada kebanyakan mesin, jauh lebih sulit untuk itu dengan cara yang mengambil keuntungan penuh dari mesin tertentu.

Sebagai contoh, itu cukup rutin bahwa jika Anda benar-benar ingin mengoptimalkan kode byte Java, Anda pada dasarnya melakukan beberapa teknik reverse untuk menerjemahkannya kembali dari representasi seperti mesin-kode, dan mengubahnya kembali menjadi instruksi SSA (atau yang serupa) 2 . Anda kemudian memanipulasi instruksi SSA untuk melakukan optimasi Anda, kemudian menerjemahkan dari sana ke sesuatu yang menargetkan arsitektur yang benar-benar Anda pedulikan. Walaupun dengan proses yang agak rumit ini, bagaimanapun, beberapa konsep yang asing ke Jawa cukup sulit untuk diutarakan bahwa sulit untuk menerjemahkan dari beberapa bahasa sumber ke dalam kode mesin yang berjalan (bahkan hampir) secara optimal pada kebanyakan mesin yang khas.

Ringkasan

Jika Anda bertanya mengapa menggunakan representasi perantara secara umum, dua faktor utama adalah:

  1. Kurangi masalah O (N * M) menjadi masalah O (N + M), dan
  2. Pecahkan masalah menjadi beberapa bagian yang lebih mudah dikelola.

Jika Anda bertanya tentang spesifikasi kode byte Java, dan mengapa mereka memilih representasi khusus ini daripada yang lain, maka saya akan mengatakan jawabannya sebagian besar kembali ke maksud aslinya dan keterbatasan web pada saat itu. , yang mengarah ke prioritas berikut:

  1. Representasi yang kompak.
  2. Cepat dan mudah untuk memecahkan kode dan mengeksekusi.
  3. Cepat dan mudah diimplementasikan pada mesin yang paling umum.

Mampu mewakili banyak bahasa atau mengeksekusi secara optimal pada berbagai target adalah prioritas yang jauh lebih rendah (jika mereka dianggap prioritas sama sekali).


  1. Jadi mengapa sebagian besar sistem-P dilupakan? Sebagian besar situasi penetapan harga. Sistem-P dijual cukup baik di Apple II, Commodore SuperPets, dll. Ketika IBM PC keluar, sistem-P adalah OS yang didukung, tetapi biaya MS-DOS lebih sedikit (dari sudut pandang kebanyakan orang, pada dasarnya dilemparkan secara gratis) dan dengan cepat memiliki lebih banyak program yang tersedia, karena itulah yang ditulis untuk Microsoft dan IBM.
  2. Sebagai contoh, ini adalah cara kerja Soot .

Cukup dekat dengan applet web: maksud awalnya adalah untuk mendistribusikan kode ke peralatan (set top box ...), dengan cara yang sama seperti RPC mendistribusikan panggilan fungsi, dan CORBA mendistribusikan objek.
ninjalj

2
Ini adalah jawaban yang bagus, dan wawasan yang baik tentang bagaimana representasi perantara yang berbeda menghasilkan pertukaran yang berbeda. :)
IMSoP

@ninjalj: Itu benar-benar Oak. Pada saat itu telah berubah menjadi Jawa, saya percaya set top box (dan ide-ide serupa) telah disimpan (meskipun saya adalah orang pertama yang mengakui bahwa ada argumen yang adil untuk dibuat bahwa Oak dan Jawa adalah hal yang sama).
Jerry Coffin

@TobySpeight: Ya, ekspresi mungkin lebih cocok di sana. Terima kasih.
Jerry Coffin

0

Selain kelebihan yang ditunjukkan orang lain, bytecode jauh lebih kecil, sehingga lebih mudah untuk mendistribusikan dan memperbarui dan menghabiskan lebih sedikit ruang di lingkungan target. Ini sangat penting dalam lingkungan yang sangat terbatas ruang.

Ini juga membuatnya lebih mudah untuk melindungi kode sumber yang dilindungi hak cipta.


2
Bytecode Java (dan .NET) sangat mudah untuk diubah menjadi sumber yang cukup terbaca sehingga ada produk untuk menguraikan nama dan terkadang informasi lain untuk membuat ini lebih sulit — sesuatu yang juga sering dilakukan pada JavaScript untuk membuatnya lebih kecil, karena kami baru saja sekarang mungkin mengatur bytecode untuk browser Web.
LnxPrgr3

0

Intinya adalah bahwa kompilasi dari kode byte ke kode mesin lebih cepat daripada menafsirkan kode asli Anda ke kode mesin tepat waktu. Tetapi kami membutuhkan interpretasi untuk membuat lintas-platform aplikasi kami, karena kami ingin menggunakan kode asli kami di setiap platform tanpa perubahan dan tanpa persiapan (kompilasi) apa pun. Jadi javac pertama mengkompilasi kode sumber kami ke byte, maka kita dapat menjalankan kode byte ini di mana saja dan itu akan ditafsirkan oleh Java Virtual Machine ke kode mesin lebih cepat. Jawabannya: menghemat waktu.


0

Awalnya, JVM adalah penerjemah murni . Dan Anda mendapatkan juru bahasa dengan kinerja terbaik jika bahasa yang Anda tafsirkan sesederhana mungkin. Itulah tujuan dari kode byte: Untuk memberikan input yang dapat ditafsirkan secara efisien ke lingkungan run-time. Keputusan tunggal ini menempatkan Java lebih dekat ke bahasa yang dikompilasi daripada ke bahasa yang ditafsirkan, sebagaimana dinilai oleh kinerjanya.

Baru kemudian, ketika tampak jelas bahwa kinerja JVM penafsiran masih payah, orang menginvestasikan upaya untuk membuat kompiler just-in-time yang berkinerja baik. Ini agak menutup celah untuk bahasa yang lebih cepat seperti C dan C ++. (Namun, beberapa masalah kecepatan inheren Java tetap ada, jadi Anda mungkin tidak akan pernah mendapatkan lingkungan Java yang berkinerja serta kode C yang ditulis dengan baik.)

Tentu saja, dengan teknik kompilasi just-in-time yang ada, kami dapat kembali untuk benar-benar mendistribusikan kode sumber, dan kompilasi just-in-time ke kode mesin. Namun, ini akan sangat mengurangi kinerja startup hingga semua bagian kode yang relevan dikompilasi. Kode byte masih sangat membantu di sini karena jauh lebih mudah untuk diuraikan daripada kode Java yang setara.


Apakah downvoter tolong menjelaskan mengapa ?
cmaster

-5

Kode Sumber Teks adalah struktur yang dimaksudkan agar mudah dibaca dan dimodifikasi oleh manusia.

Kode byte adalah struktur yang dimaksudkan untuk mudah dibaca dan dieksekusi oleh mesin.

Karena semua JVM tidak dengan kode dibaca dan dijalankan, kode byte lebih cocok untuk dikonsumsi oleh JVM.

Saya perhatikan bahwa belum ada contoh. Contoh Pseudo yang konyol:

//Source code
i += 1 + 5 * 2 + x;

// Byte code
i += 11, i += x
____

//Source code
i = sin(1);

// Byte code
i = 0.8414709848
_____

//Source code
i = sin(x)^2+cos(x)^2;

// Byte code (actually that one isn't true)
i = 1

Tentu saja kode byte bukan hanya tentang pengoptimalan. Sebagian besar dari itu adalah tentang dapat mengeksekusi kode tanpa harus peduli dengan aturan yang rumit, seperti memeriksa apakah kelas berisi anggota yang disebut "foo" di suatu tempat lebih jauh dalam file ketika suatu metode merujuk ke "foo".


2
"Contoh" kode byte itu bisa dibaca manusia. Itu bukan kode byte sama sekali. Ini menyesatkan dan juga tidak menjawab pertanyaan yang diajukan.
Wildcard

@ Kartu Memori Anda mungkin melewatkan forum ini, dibaca oleh manusia. Itu sebabnya saya meletakkan konten dalam bentuk yang dapat dibaca manusia. Mengingat bahwa forum adalah tentang rekayasa perangkat lunak, meminta pembaca untuk memahami konsep abstraksi sederhana tidak banyak bertanya.
Peter

Bentuk yang dapat dibaca manusia adalah kode sumber, bukan kode byte. Anda mengilustrasikan kode sumber dengan ekspresi yang sudah dihitung sebelumnya, bukan kode byte. Dan saya tidak ketinggalan bahwa ini adalah forum yang bisa dibaca manusia: Andalah yang mengkritik penjawab lain karena tidak memasukkan contoh kode byte, bukan saya. Jadi Anda berkata, "Saya perhatikan belum ada contoh," dan kemudian lanjutkan untuk memberikan non- contoh yang tidak menggambarkan kode byte sama sekali. Dan ini masih tidak menjawab pertanyaan sama sekali. Baca kembali pertanyaannya.
Wildcard
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.