Apa arti tuntutan Sun terhadap Microsoft untuk pembangun Java?

7 Oktober 1997 - Sun telah menanggapi pelepasan Microsoft Internet Explorer (IE) 4.0, dan peluncuran 2.0 dari SDK untuk Java (SDKJ) dengan tuntutan hukum di Mahkamah Daerah AS. Menurut siaran pers Sun, "keluhan tersebut menuduh Microsoft dengan pelanggaran tanda dagang, iklan palsu, pelanggaran kontrak, persaingan tidak adil, campur tangan dengan prospek keuntungan ekonomi, dan mendorong pelanggaran kontrak." Secara khusus, Microsoft membuat pilihan minggu lalu untuk menghantar produk yang diklaimnya sepenuhnya mematuhi Java 1.1, tetapi gagal lulus ujian keserasian Java 1.1 yang diterima syarikat dari Sun pada bulan Februari. "Microsoft memulai tingkah laku yang disengaja untuk memecah-belahkan Java," kata Alan Baratz, presiden JavaSoft, dalam telekonferensi Sun hari ini pada pukul 10:30 pagi PST.

Dari perspektif pemaju, apakah maksudnya? Baiklah, pertama, jika anda membuat sesuatu dengan Sun JDK 1.1 (atau dengan persekitaran yang disahkan oleh Java 1.1 dari syarikat lain, seperti IBM, Borland, dan Symantec), ia mungkin tidak dijalankan di bawah IE 4.0. Juga, jika anda membuat sesuatu dengan lingkungan pengembangan Microsoft, ia mungkin tidak berjalan di bawah lingkungan Java Microsoft 1.1 yang bukan. Secara khusus, Microsoft tidak menyokong Java Native Interfaces (JNI) atau Remote Method Invocation (RMI), dan telah mengubah perpustakaan kelas Core Java dengan kira-kira 50 kaedah dan 50 bidang yang bukan merupakan bahagian dari Java Application Programming Interfaces ( API) yang diterbitkan oleh Sun.

JNI dan RMI: Mengapa penolakan Microsoft terhadap perkara ini menimbulkan masalah

JNI adalah antara muka kod asli yang digunakan untuk mengakses keupayaan khusus platform seperti port bersiri atau mikrofon - untuk perkara yang belum tersedia melalui inti API. Matlamat JNI adalah untuk membolehkan pembangun menyediakan satu set perpustakaan asli untuk setiap pelaksanaan Java pada platform tertentu.

Microsoft telah memutuskan untuk menyokong antara muka sendiri, yang disebut RNI, yang memberikan kemampuan yang sama seperti JNI. Dengan tidak menyokong JNI, Microsoft memaksa para pembangun untuk menyediakan perpustakaan yang berbeza untuk pengguna Microsoft dan mesin virtual Java (JVM) Microsoft. Tidak ada yang salah dengan sokongan Microsoft terhadap RNI sekiranya syarikat berpendapat teknologinya lebih baik. Namun, dengan tidak menyokong JNI, Microsoft tidak dapat mendakwa IE 4.0 sepenuhnya mematuhi Java 1.1.

RMI menyediakan kaedah untuk melaksanakan kod Java pada mesin maya Java asing. Ia sering dibandingkan dengan Panggilan Prosedur Jauh (RPC), Binaan Permintaan Objek Umum Broker (CORBA), dan Model Objek Komponen Teragih (DCOM), bergantung pada latar belakang orang yang bercakap. Microsoft mendakwa ia menyokong DCOM dan bukannya RMI kerana RMI tidak menyokong komunikasi Java-ke-bukan-Java. Tujuan khusus untuk menggunakan RMI adalah untuk komunikasi sistem Java-ke-Java. Sebagai contoh, dengan RMI, anda boleh menggunakan kaedah objek yang ada di mesin maya Java lain, tanpa mengetahui jenis kelas, sambil menjaga keselamatan runtime Java.

Sekiranya anda perlu bergerak di luar komunikasi Java-ke-Java, CORBA sebenarnya adalah penyelesaian mudah alih, bukan DCOM. Kenapa? DCOM diarahkan ke dunia Microsoft, baru-baru ini tersedia untuk dunia Unix dengan produk seperti EntireX dari Software AG. Sekiranya anda perlu menggunakan RMI, jelas Internet Explorer bukanlah pilihan yang tersedia. Sekiranya anda memerlukan komunikasi sistem Java-ke-bukan-Java, untuk berinteraksi dengan sistem-sistem lama (bukan-Java) yang bergantung pada CORBA, Netscape Communicator 4.0 disertakan dengan VisiBroker ORB Visigenic. (Untuk sokongan RMI dengan Netscape Communicator, anda perlu menggunakan pelepasan beta patch penyemak imbas, kerana Communicator tidak mengaku sebagai penyemak imbas Java 1.1.)

Busuk ke Core Java API: Inti dari masalah

Masalah ketidakcocokan Java 1.1 yang terakhir dikenal pasti sebenarnya paling menakutkan. Sangat mudah untuk mengelakkan RMI dan JNI jika aplikasi anda mengizinkannya: Anda tidak menggunakannya. Yang penting ialah Microsoft memutuskan bahawa perpustakaan kelas Core Java tidak mencukupi untuk keperluannya. Sekarang tidak ada yang salah dengan memperluas perkara dengan subkelas dan meletakkan objek baru dalam pakej di luar hierarki kelas. Tetapi memutuskan untuk menambahkan sekitar 50 kaedah dan 50 medan ke dalam kelas dalam pakej java.awt, java.lang, dan java.io, seperti yang dilakukan Microsoft, sangat bermasalah. "Microsoft dengan sengaja mengubah kelas utama dan memasukkannya ke dalam SDK mereka," kata Baratz, yang mengakibatkan para pembangun menyangka mereka menulis Java, padahal sebenarnya mereka menulis sesuatu yang hanya berjalan di Internet Explorer.

Bagaimana penambahan Microsoft ke kelas mempengaruhi pemaju Java? Jika anda bergantung pada perubahan ini, atau menggunakannya secara tidak sengaja, program anda hanya akan berfungsi dalam sistem Java Microsoft. Juga, jika anda membuat program di luar lingkungan pengembangan Microsoft, ia akan memerlukan API teras tertentu. Sayangnya, Core API itu berbeza dari yang ada dalam persekitaran Microsoft, jadi program ini mungkin tidak berfungsi di sana. Ujian keserasian yang menandakan masalah ini adalah apa yang dipanggil a signature test.

Sebagai contoh, jika kaedah foo()seharusnya menerima parameter jenis bar, lebih baik mendapatkan objek jenis bar. Sekiranya seseorang menginginkan anda memasukkan objek jenis baz, ia hanya akan berfungsi pada sistem yang mengubah intinya untuk menerimanya. Dan, Microsoft memperkenalkan perubahan itu. Sekarang, Microsoft mungkin menganggapnya sebagai referensi pelaksanaan Java untuk Windows. Tetapi kenyataannya, hanya Sun yang dapat memperkenalkan perubahan pada Core Java API. Ya, mana-mana pemegang lesen boleh meminta perubahan, dan banyak yang sering melakukannya. Tetapi Microsoft secara sendirian, dan tanpa izin, memutuskan untuk mengubah perkara ini.

Pada akhirnya, tujuan tuntutan itu adalah, dalam kata-kata Baratz, "untuk membuat Microsoft kembali patuh," dan secepat mungkin. Tetapi sampai keabsahannya diselesaikan, Sun akan menahan dari Microsoft semua peningkatan teknologi Java yang sedang berlangsung, seperti mesin maya Java 2.0 baru yang disebut HotSpot. Sekiranya Microsoft tidak lagi mematuhi Java, ia harus dilengkapi dengan implementasi ruang bersih dari versi sesuatu yang tidak akan disebut Java - iaitu, jika ia ingin melakukan sesuatu dengan setara bykod Java. Siapa tahu apa yang akan berlaku pada IE 4.0, SDK untuk Java 2.0, dan Visual J ++ seterusnya?

Kata-kata hikmat: Biarkan pemaju Java berhati-hati

Sebagai pemaju, anda harus mengikuti dengan teliti. Sekiranya anda memutuskan untuk menggunakan persekitaran pengembangan Microsoft dan perlu membuat penyelesaian merentas platform, sangat akrab dengan Core Java APIs. Anda harus mengelakkan sesuatu yang bukan sebahagian daripada spesifikasi awam. Sehingga senarai lengkap elemen tidak serasi diterbitkan, tanggungjawab pemaju individu akan mengetahui apa yang tidak dan tidak serasi. Sudah tentu, jika anda tidak peduli dengan "tulis-sekali, jalankan di mana sahaja," anda boleh menggunakan kemampuan khusus platform Microsoft. Namun, ada kemungkinan bahawa lesen Java Microsoft akan dicabut. Sun sudah berusaha untuk mencabut kemampuan Microsoft untuk menampilkan logo yang sesuai dengan Java.

John Zukowski adalah Software Mage dengan MageLang Institute, pengarang Java AWT Reference dari O'Reilly & Associates dan Borland's JBuilder: Tidak diperlukan pengalaman dari Sybex, serta panduan Focus on Java di Syarikat Perlombongan.

Ketahui lebih lanjut mengenai topik ini

  • Siaran akhbar Sun Microsystems

    //java.sun.com/announcement/index.html

  • Soalan Lazim Microsoft mengenai mengapa ia tidak menyokong RMI / JNI, dan sebagainya

    //www.microsoft.com/java/issues/techsupfaq.htm

  • Sokongan Netscape untuk Java dalam Communicator 4.0

    //developer.netscape.com/library/documentation/communicator/javajdk.html

  • Lihat kisah oleh Elizabeth Heichler, dari News Service, dan Bob McMillan, SunWorld

    //www.javaworld.com/jw-10-1997/jw-10-sunsuit.html

  • Jenni Aloi kita sendiri menulis kisah kemarahan Java Lobby terhadap Microsoft

    //www.javaworld.com/jw-10-1997/jw-10-javalobby.html

  • Kisah CNet mengenai saman Sun terhadap Microsoft

    //www.news.com/News/Item/0,4,14986,00.html

  • Berita San Jose Mercury mengenai tuntutan mahkamah

    //www.sjmercury.com/business/sunsuit100797.htm

  • Sekiranya Microsoft dibenarkan untuk mengubah perpustakaan kelas utama Java? Ikuti tinjauan terbaru kami

    //nigeria.wpi.com/cgi-bin/gwpoll/gwpoll/ballot.html

  • Kajian mengenai alat pengembangan Java yang tidak platform-platform di NC World , penerbitan saudara JavaWorld

    //www.ncworldmag.com/ncw-10-1997/ncw-10-jvtools.html

  • Komen Nick Petreley mengenai tuntutan mahkamah Sun / MS, juga di NC World

    //www.ncworldmag.com/ncw-10-1997/ncw-10-straypackets.html

Kisah ini, "Apa arti tuntutan hukum Sun terhadap Microsoft bagi pemaju Java?" pada asalnya diterbitkan oleh JavaWorld.