Tiga jenis portabilitas Java

Java telah menghasilkan banyak kegembiraan dalam komunitas pemrograman karena menjanjikan aplikasi dan applet portabel . Faktanya, Java menyediakan tiga jenis portabilitas yang berbeda: portabilitas kode sumber, portabilitas arsitektur CPU, dan portabilitas OS / GUI. Fakta bahwa ada tiga jenis portabilitas yang berbeda sangat penting, karena hanya satu dari jenis ini yang merupakan ancaman bagi Microsoft. Microsoft dapat diharapkan untuk merusak satu jenis portabilitas sambil merangkul dua lainnya - sambil mengklaim mendukung Java. Memahami tiga jenis portabilitas dan bagaimana mereka bekerja sama sangat penting untuk memahami ancaman terhadap Microsoft, dan kemungkinan tanggapan Microsoft.

Sebelum membahas detail masing-masing dari ketiga jenis portabilitas ini, mari kita tinjau beberapa istilah mendasar.

Mendefinisikan beberapa istilah

Istilah berikut digunakan dalam artikel ini:

Endianisme
Endianisme mengacu pada urutan penyimpanan byte dalam kuantitas multibyte dalam CPU tertentu. Misalnya, 256 pendek unsigned (desimal) membutuhkan dua byte penyimpanan: 0x01 dan 0x00. Kedua byte ini dapat disimpan dalam urutan: 0x01, 0x00atau 0x00, 0x01. Endianisme menentukan urutan penyimpanan dua byte. Untuk tujuan praktis, endianisme biasanya penting hanya jika CPU dari endianisme yang berbeda harus berbagi data.
Jawa
Java adalah beberapa teknologi berbeda yang dikemas bersama - bahasa pemrograman Java, mesin virtual Java (JVM), dan pustaka kelas yang terkait dengan bahasa tersebut. Artikel ini membahas semua aspek tersebut.
Mesin virtual Java (JVM)

JVM adalah CPU imajiner yang sebagian besar kompiler Java memancarkan kode. Dukungan untuk CPU imajiner inilah yang memungkinkan program Java berjalan tanpa dikompilasi ulang pada CPU yang berbeda. Tidak ada dalam bahasa pemrograman Java yang memerlukan kode sumber Java untuk dikompilasi menjadi kode untuk JVM, bukan menjadi kode objek asli.

Faktanya, Asymetrix dan Microsoft telah mengumumkan compiler Java yang mengeluarkan aplikasi Microsoft Windows asli. (Lihat bagian Sumber dari artikel ini untuk informasi tambahan.)

Kode-J
J-code adalah keluaran yang dikeluarkan oleh sebagian besar kompiler Java ke dalam file kelas. J-code dapat dianggap sebagai kode objek untuk mesin virtual Java.
Portabilitas
Portabilitas mengacu pada kemampuan untuk menjalankan program pada mesin yang berbeda. Menjalankan program tertentu pada mesin yang berbeda dapat memerlukan jumlah pekerjaan yang berbeda (misalnya, tidak ada pekerjaan apa pun, kompilasi ulang, atau membuat perubahan kecil pada kode sumber). Ketika orang menyebut aplikasi dan applet Java sebagai portabel, yang mereka maksud adalah aplikasi dan applet berjalan di berbagai jenis mesin tanpa perubahan (seperti kompilasi ulang atau tweak ke kode sumber).

Sekarang setelah kami membahas beberapa istilah penting, kami akan menjelaskan masing-masing dari tiga jenis portabilitas Java.

Java sebagai bahasa: portabilitas kode sumber

Sebagai bahasa pemrograman, Java menyediakan bentuk portabilitas yang paling sederhana dan paling dikenal - portabilitas kode sumber. Program Java yang diberikan harusmenghasilkan hasil yang identik terlepas dari CPU yang mendasarinya, sistem operasi, atau kompiler Java. Ide ini bukanlah hal baru; bahasa seperti C dan C ++ telah memberikan peluang untuk tingkat portabilitas ini selama bertahun-tahun. Namun, C dan C ++ juga memberikan banyak peluang untuk membuat kode non-portabel juga. Kecuali program yang ditulis dalam C dan C ++ dirancang untuk menjadi portabel sejak awal, kemampuan untuk berpindah ke mesin yang berbeda lebih bersifat teoretis daripada praktis. C dan C ++ meninggalkan detail yang tidak ditentukan seperti ukuran dan endianisme tipe data atom, perilaku matematika floating-point, nilai variabel yang tidak diinisialisasi, dan perilaku saat memori yang dibebaskan diakses.

Singkatnya, meskipun sintaks C dan C ++ didefinisikan dengan baik, semantiknya tidak. Kelonggaran semantik ini memungkinkan satu blok kode sumber C atau C ++ untuk dikompilasi ke program yang memberikan hasil berbeda ketika dijalankan pada CPU, sistem operasi, kompiler yang berbeda, dan bahkan pada kombinasi kompilator / CPU / OS tunggal, bergantung pada berbagai pengaturan kompilator. (Lihat Sintaks sidebar versus semantik untuk diskusi tentang perbedaan antara semantik dan sintaks.)

Jawa berbeda. Java menyediakan semantik yang jauh lebih ketat dan lebih sedikit menyerahkan kepada pelaksana. Tidak seperti C dan C ++, Java telah menetapkan ukuran dan endianisme untuk jenis atom, serta perilaku titik mengambang yang ditentukan.

Selain itu, Java mendefinisikan lebih banyak perilaku daripada C dan C ++. Di Java, memori tidak dibebaskan sampai tidak bisa diakses lagi, dan bahasa tidak memiliki variabel yang tidak diinisialisasi. Semua fitur ini membantu mempersempit variasi perilaku program Java dari platform ke platform dan implementasi ke implementasi. Bahkan tanpa JVM, program yang ditulis dalam bahasa Java dapat diharapkan untuk porting (setelah kompilasi ulang) ke CPU yang berbeda dan sistem operasi yang jauh lebih baik daripada program C atau C ++ yang setara.

Sayangnya, fitur-fitur yang menjadikan Java begitu portabel memiliki kekurangan. Java mengasumsikan mesin 32-bit dengan byte 8-bit dan matematika floating-point IEEE754. Mesin yang tidak cocok dengan model ini, termasuk mikrokontroler 8-bit dan superkomputer Cray, tidak dapat menjalankan Java secara efisien. Untuk alasan ini, kita harus mengharapkan C dan C ++ digunakan pada lebih banyak platform daripada bahasa Java. Kita juga harus mengharapkan program Java untuk melakukan port lebih mudah daripada C atau C ++ antara platform yang mendukung keduanya.

Java sebagai mesin virtual: portabilitas CPU

Kebanyakan kompiler menghasilkan kode objek yang berjalan pada satu keluarga CPU (misalnya, keluarga Intel x86). Bahkan kompiler yang menghasilkan kode objek untuk beberapa keluarga CPU yang berbeda (misalnya, x86, MIPS, dan SPARC) hanya menghasilkan kode objek untuk satu jenis CPU pada satu waktu; jika Anda memerlukan kode objek untuk tiga keluarga CPU yang berbeda, Anda harus mengkompilasi kode sumber Anda tiga kali.

Kompiler Java saat ini berbeda. Alih-alih menghasilkan keluaran untuk setiap keluarga CPU yang berbeda di mana program Java dimaksudkan untuk dijalankan, kompiler Java saat ini menghasilkan kode objek (disebut J-code) untuk CPU yang belum ada.

(Sun telah mengumumkan CPU yang akan mengeksekusi J-code secara langsung, tetapi menunjukkan sampel pertama chip Java tidak akan muncul hingga paruh kedua tahun ini; produksi penuh dari chip tersebut akan dimulai tahun depan. Teknologi inti picoJavaI Sun Microelectronics akan berada di jantung lini prosesor microJava Sun sendiri, yang akan menargetkan komputer jaringan. Penerima lisensi seperti LG Semicon, Toshiba Corp., dan Rockwell Collins Inc. juga berencana untuk memproduksi chip Java berdasarkan inti picoJavaI.)

Untuk setiap CPU nyata tempat program Java dimaksudkan untuk dijalankan, juru bahasa Java, atau mesin virtual, "mengeksekusi" J-code. CPU yang tidak ada ini memungkinkan kode objek yang sama untuk dijalankan pada CPU mana pun yang memiliki interpreter Java.

Memproduksi output untuk CPU imajiner bukanlah hal baru dengan Java: Kompiler Pascal UCSD (University of California di San Diego) menghasilkan P-code bertahun-tahun yang lalu; Limbo, bahasa pemrograman baru yang sedang dikembangkan di Lucent Technologies, menghasilkan kode objek untuk CPU imajiner; dan Perl membuat representasi program perantara dan mengeksekusi representasi perantara ini daripada membuat kode eksekusi asli. JVM yang paham Internet membedakan dirinya dari implementasi CPU virtual lainnya dengan sengaja dirancang untuk memungkinkan pembuatan kode yang terbukti aman dan bebas virus. Sebelum ada Internet, mesin virtual tidak perlu membuktikan program aman dan bebas virus. Fitur keamanan ini, dikombinasikan dengan pemahaman yang jauh lebih baik tentang bagaimana menjalankan program dengan cepat untuk CPU imajiner, telah menghasilkan,penerimaan JVM secara luas. Saat ini, sebagian besar sistem operasi utama, termasuk OS / 2, MacOS, Windows 95 / NT, dan Novell Netware, memiliki, atau diharapkan memiliki, dukungan bawaan untuk program J-code.

JVM, yang pada dasarnya merupakan CPU imajiner, tidak bergantung pada bahasa kode sumber. Bahasa Java bisa menghasilkan J-code. Tapi begitu juga Ada95. Faktanya, penerjemah yang dihosting kode-J telah ditulis untuk beberapa bahasa, termasuk BASIC, Forth, Lisp, dan Skema, dan hampir pasti bahwa implementasi bahasa lain akan mengeluarkan kode-J di masa mendatang. Setelah kode sumber diubah menjadi kode-J, juru bahasa Java tidak dapat mengetahui bahasa pemrograman apa yang membuat kode-J yang dieksekusi. Hasilnya: portabilitas antara berbagai CPU.

Manfaat dari mengkompilasi program (dalam bahasa apapun) ke J-code adalah bahwa kode yang sama berjalan pada keluarga CPU yang berbeda. Kekurangannya adalah J-code tidak bekerja secepat kode asli. Untuk sebagian besar aplikasi, ini tidak masalah, tetapi untuk program high-end tertinggi - yang membutuhkan setiap persen terakhir dari CPU - biaya kinerja J-code tidak akan dapat diterima.

Java sebagai OS virtual dan GUI: portabilitas OS

Kebanyakan program Microsoft Windows yang ditulis dalam C atau C ++ tidak mudah diport ke lingkungan Macintosh atau Unix, bahkan setelah kompilasi ulang. Bahkan jika pemrogram lebih berhati-hati untuk mengatasi kelemahan semantik di C atau C ++, portnya sulit. Kesulitan ini terjadi bahkan ketika port ke sistem operasi non-Windows berlangsung tanpa mengubah CPU. Mengapa kesulitan?

Setelah menghilangkan masalah semantik di C dan C ++ dan masalah port CPU, programmer masih harus berurusan dengan sistem operasi yang berbeda dan panggilan API GUI yang berbeda.

Program Windows membuat panggilan yang sangat berbeda ke sistem operasi daripada program Macintosh dan Unix. Panggilan ini sangat penting untuk menulis program non-sepele, jadi sampai masalah portabilitas ini diatasi, porting akan tetap sulit.

Java memecahkan masalah ini dengan menyediakan satu set fungsi perpustakaan (yang terdapat di Jawa-disediakan perpustakaan seperti awt, util, dan lang) yang berbicara dengan OS imajiner dan GUI imajiner. Sama seperti JVM yang menyajikan CPU virtual, perpustakaan Java menghadirkan OS / GUI virtual. Setiap implementasi Java menyediakan pustaka yang mengimplementasikan OS / GUI virtual ini. Program Java yang menggunakan pustaka ini menyediakan port fungsionalitas OS dan GUI yang dibutuhkan dengan cukup mudah.

Menggunakan pustaka portabilitas sebagai ganti panggilan OS / GUI asli bukanlah ide baru. Produk seperti Visix Software's Galaxy dan Protools Software's Zinc menyediakan kemampuan ini untuk C dan C ++. Pendekatan lain, tidak diikuti oleh Java, adalah memilih satu OS / GUI sebagai master dan menyediakan pustaka pembungkus yang mendukung OS / GUI master ini pada semua mesin yang ingin Anda port. Masalah dengan pendekatan OS / GUI master adalah bahwa aplikasi porting sering terlihat asing di mesin lain. Pengguna Macintosh, misalnya, mengeluh tentang versi terbaru Microsoft Word untuk Macintosh karena tampilannya dan berperilaku seperti program Windows, bukan seperti program Macintosh. Sayangnya, pendekatan yang diambil Java juga bermasalah.

Java telah menyediakan fungsionalitas penyebut yang paling tidak umum di pustaka OS / GUI-nya. Fitur yang hanya tersedia pada satu OS / GUI, seperti kotak dialog bertab, dihilangkan. Keuntungan dari pendekatan ini adalah bahwa memetakan fungsionalitas umum ke OS / GUI asli cukup mudah dan, dengan hati-hati, dapat menyediakan aplikasi yang berfungsi seperti yang diharapkan pada kebanyakan OS / GUI. Kerugiannya adalah akan ada fungsionalitas yang tersedia untuk aplikasi mode asli yang tidak tersedia untuk aplikasi Java. Kadang-kadang pengembang akan dapat mengatasi ini dengan memperluas AWT; di lain waktu mereka tidak mau. Dalam kasus di mana fungsionalitas yang diinginkan tidak dapat dicapai dengan solusi, pengembang kemungkinan besar akan memilih untuk menulis kode non-portabel.

Siapa yang peduli dengan portabilitas?

Tiga konstituen utama peduli tentang portabilitas: pengembang, pengguna akhir, dan departemen MIS.

Pengembang: Peluang dan ancaman tampak besar

Pengembang memiliki kepentingan dalam membuat perangkat lunak portabel. Sisi baiknya, perangkat lunak portabel memungkinkan mereka mendukung lebih banyak platform, yang mengarah ke basis pelanggan potensial yang lebih besar. Namun, portabilitas yang sama yang memungkinkan pengembang menargetkan pasar baru juga memungkinkan pesaing menargetkan pasar mereka.

Singkatnya, portabilitas Java mendorong pasar perangkat lunak aplikasi menjauh dari pasar terpisah berdasarkan berbagai OS dan GUI dan menuju satu pasar besar. Di pasar perangkat lunak saat ini, misalnya, Microsoft adalah kekuatan yang harus diperhitungkan di pasar perangkat lunak aplikasi Windows dan Macintosh, tetapi hampir tidak ada di pasar OS / 2 dan Unix. Pemartisian ini memungkinkan perusahaan di pasar OS / 2 dan Unix mengabaikan Microsoft sebagai pesaing. Java mempermudah perusahaan-perusahaan ini untuk bersaing di pasar Windows, tetapi juga memungkinkan Microsoft lebih mudah masuk ke pasar OS / 2 dan Unix.

Pengguna: Penerima manfaat tidak langsung dari portabilitas

Pengguna tidak peduli dengan portabilitas, per se. Jika portabilitas membuat hidup mereka lebih mudah dan menyenangkan, maka mereka mendukung; jika tidak, mereka tidak. Portabilitas memang memiliki beberapa efek positif bagi pengguna, tetapi ini agak tidak langsung. Efek positifnya: