Was bedeutet die Klage von Sun gegen Microsoft für Java-Entwickler?

7. Oktober 1997 - Sun hat auf die Veröffentlichung von Internet Explorer (IE) 4.0 durch Microsoft und die Veröffentlichung des SDK für Java (SDKJ) 2.0 durch Microsoft mit einer Klage vor dem US-Bezirksgericht reagiert. Laut der Pressemitteilung von Sun "beschuldigt die Beschwerde Microsoft Markenverletzung, falsche Werbung, Vertragsverletzung, unlauteren Wettbewerb, Beeinträchtigung des potenziellen wirtschaftlichen Vorteils und Verursachung einer Vertragsverletzung." Insbesondere hat Microsoft letzte Woche die Entscheidung getroffen, Produkte zu versenden, von denen behauptet wird, dass sie vollständig Java 1.1-kompatibel sind, die jedoch die Java 1.1-Kompatibilitätstests, die das Unternehmen im Februar von Sun erhalten hat, nicht bestanden haben. "Microsoft hat ein bewusstes Verhalten eingeleitet, um Java zu fragmentieren", sagte Alan Baratz, Präsident von JavaSoft, während einer Sun-Telefonkonferenz heute um 10:30 Uhr PST.

Was bedeutet dies aus Entwicklersicht? Wenn Sie etwas mit dem 1.1 JDK von Sun (oder mit der Java 1.1-zertifizierten Umgebung eines anderen Unternehmens wie IBM, Borland und Symantec) erstellen, wird es möglicherweise nicht unter IE 4.0 ausgeführt. Wenn Sie etwas mit der Entwicklungsumgebung von Microsoft erstellen, wird es möglicherweise nicht unter einer Nicht-Microsoft Java 1.1-Umgebung ausgeführt. Insbesondere unterstützt Microsoft weder die Java Native Interfaces (JNI) noch den Remote Method Invocation (RMI) und hat die Java-Kernklassenbibliotheken mit etwa 50 Methoden und 50 Feldern geändert, die nicht Teil der öffentlichen Java Application Programming Interfaces sind ( APIs) veröffentlicht von Sun.

JNI und RMI: Warum die Ablehnung durch Microsoft ein Problem darstellt

JNI ist die native Codeschnittstelle für den Zugriff auf plattformspezifische Funktionen wie eine serielle Schnittstelle oder ein Mikrofon - für Dinge, die noch nicht über die Kern-API verfügbar sind. Das Ziel von JNI ist es, Entwicklern die Bereitstellung eines einzigen Satzes nativer Bibliotheken für jede Java-Implementierung auf einer bestimmten Plattform zu ermöglichen.

Microsoft hat beschlossen, eine eigene Schnittstelle namens RNI zu unterstützen, die dieselben Funktionen wie JNI bietet. Da Microsoft JNI nicht unterstützt, zwingt Microsoft Entwickler, verschiedene Bibliotheken für Benutzer von Microsoft und Nicht-Microsoft Java Virtual Machine (JVM) bereitzustellen. An der Unterstützung von RNI durch Microsoft ist nichts auszusetzen, wenn das Unternehmen der Meinung ist, dass seine Technologie besser ist. Da Microsoft JNI nicht unterstützt, kann Microsoft nicht behaupten, dass IE 4.0 vollständig Java 1.1-kompatibel ist.

RMI bietet eine Möglichkeit, Java-Code auf fremden virtuellen Java-Maschinen auszuführen. Es wird häufig mit Remote Procedure Calls (RPC), der Common Object Request Broker-Architektur (CORBA) und dem Distributed Component Object Model (DCOM) verglichen, abhängig vom Hintergrund der sprechenden Person. Microsoft behauptet, DCOM anstelle von RMI zu unterstützen, da RMI keine Java-zu-Nicht-Java-Kommunikation unterstützt. Der spezielle Zweck für die Verwendung von RMI ist die Kommunikation von Java zu Java-Systemen. Mit RMI können Sie beispielsweise Methoden von Objekten aufrufen, die in anderen virtuellen Java-Maschinen vorhanden sind, ohne den Klassentyp zu kennen, während die Laufzeitsicherheit von Java erhalten bleibt.

Wenn Sie außerhalb der Java-zu-Java-Kommunikation wechseln müssen, ist CORBA tatsächlich die tragbare Lösung, nicht DCOM. Warum? DCOM ist auf die Microsoft-Welt ausgerichtet und wird erst seit kurzem mit Produkten wie EntireX von der Software AG für die Unix-Welt verfügbar. Wenn Sie RMI verwenden müssen, ist Internet Explorer offensichtlich keine verfügbare Option. Wenn Sie eine Java-zu-Nicht-Java-Systemkommunikation benötigen, um mit Legacy-Systemen (Nicht-Java-Systemen) zu kommunizieren, die auf CORBA basieren, wird Netscape Communicator 4.0 mit Visigenics VisiBroker ORB geliefert. (Für die RMI-Unterstützung mit Netscape Communicator müssen Sie eine Beta-Version eines Browser-Patches verwenden, da Communicator nicht behauptet, ein Java 1.1-Browser zu sein.)

Faul auf die Core Java API: Der Kern des Problems

Das letzte festgestellte Java 1.1-Inkompatibilitätsproblem ist tatsächlich das gruseligste. Es ist leicht, RMI und JNI zu vermeiden, wenn Ihre Anwendung dies zulässt: Sie verwenden sie einfach nicht. Der Knackpunkt ist, dass Microsoft entschieden hat, dass die Core Java-Klassenbibliotheken für ihre Anforderungen nicht ausreichen. Jetzt ist nichts mehr falsch daran, Dinge durch Unterklassen und Platzieren der neuen Objekte in einem Paket außerhalb der Java. * -Klassenhierarchie zu erweitern. Die Entscheidung, wie Microsoft etwa 50 Methoden und 50 Felder zu den Klassen in den Paketen java.awt, java.lang und java.io hinzuzufügen, ist jedoch äußerst problematisch. "Microsoft hat Schlüsselklassen täuschend geändert und in sein SDK eingefügt", sagte Baratz, was dazu führt, dass Entwickler denken, sie schreiben Java, wenn sie tatsächlich etwas schreiben, das nur im Internet Explorer ausgeführt wird.

Wie wirken sich die Ergänzungen von Microsoft zu den Klassen auf Java-Entwickler aus? Wenn Sie sich auf diese Änderungen verlassen oder sie nur versehentlich verwenden, funktioniert Ihr Programm nur im Java-System von Microsoft. Wenn Sie ein Programm außerhalb der Microsoft-Entwicklungsumgebung erstellen, wird eine bestimmte Kern-API erwartet. Leider unterscheidet sich diese Core-API von der in der Microsoft-Umgebung, sodass das Programm dort möglicherweise nicht funktioniert. Der Kompatibilitätssuite-Test, der dieses Problem kennzeichnete, wird als a bezeichnet signature test.

Wenn die Methode beispielsweise foo()einen Parameter vom Typ Typ akzeptieren soll bar, ist es besser, ein Objekt vom Typ zu erhalten bar. Wenn jemand möchte, dass Sie bazstattdessen ein Objekt vom Typ übergeben , funktioniert dies nur auf den Systemen, die den Kern geändert haben, um es zu akzeptieren. Und Microsoft hat diese Änderung eingeführt. Microsoft könnte nun denken, dass dies die Referenzimplementierung von Java für Windows ist. Tatsache ist jedoch, dass nur Sun Änderungen an der Core Java API vornehmen kann. Ja, kann jeder Lizenznehmer fragen für Änderungen und viele häufig tun. Microsoft entschied sich jedoch im Alleingang und ohne Erlaubnis, diese Dinge zu ändern.

Letztendlich ist das Ziel der Klage nach Baratz 'Worten, "Microsoft wieder in Übereinstimmung zu bringen" und dies so schnell wie möglich. Bis die gesetzlichen Bestimmungen geklärt sind, wird Sun Microsoft alle laufenden Verbesserungen der Java-Technologie vorenthalten, beispielsweise die neue virtuelle Java 2.0-Maschine namens HotSpot. Wenn Microsoft nicht wieder mit Java kompatibel ist, muss es eine Reinraumimplementierung seiner Version von etwas entwickeln, das nicht Java heißt - das heißt, wenn es etwas mit dem Äquivalent tun möchte von Java-Bytecodes. Wer weiß, was mit IE 4.0, dem SDK für Java 2.0 und dem nächsten Visual J ++ passieren wird?

Worte der Weisheit: Lassen Sie den Java-Entwickler aufpassen

Als Entwickler müssen Sie sehr vorsichtig vorgehen. Wenn Sie sich für die Verwendung der Entwicklungsumgebungen von Microsoft entscheiden und plattformübergreifende Lösungen erstellen müssen, sollten Sie mit den Core Java-APIs vertraut sein. Sie müssen alles vermeiden, was nicht Teil der öffentlichen Spezifikationen ist. Bis eine vollständige Liste inkompatibler Elemente veröffentlicht ist, müssen die einzelnen Entwickler wissen, was kompatibel ist und was nicht. Wenn Sie sich nicht für "Einmal schreiben, irgendwo ausführen" interessieren, können Sie natürlich die plattformspezifischen Funktionen von Microsoft verwenden. Es ist jedoch möglich, dass die Java-Lizenz von Microsoft widerrufen wird. Sun versucht bereits, Microsoft die Möglichkeit zu widerrufen, das Java-kompatible Logo anzuzeigen.

John Zukowski ist ein Software-Magier beim MageLang Institute, Autor der Java AWT-Referenz von O'Reilly & Associates und Borlands JBuilder: Keine Erfahrung von Sybex sowie des Leitfadens „Fokus auf Java“ bei der Mining Company.

Erfahren Sie mehr über dieses Thema

  • Pressemitteilung von Sun Microsystems

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

  • Microsoft-FAQ, warum RMI / JNI nicht unterstützt wird, und so weiter

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

  • Die aktuelle Unterstützung von Netscape für Java in Communicator 4.0

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

  • Sehen Sie sich die Geschichte von Elizabeth Heichler vom News Service und Bob McMillan von SunWorld an

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

  • Unsere eigene Jenni Aloi hat eine Geschichte über die Wut der Java-Lobby auf Microsoft geschrieben

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

  • CNets Geschichte über den Sun-Anzug gegen Microsoft

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

  • San Jose Mercury News über die Klage

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

  • Sollte Microsoft die Schlüsselklassenbibliotheken von Java ändern dürfen? Nehmen Sie an unserer letzten Umfrage teil

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

  • Ein Überblick über plattformneutrale Java-Entwicklungstools in NC World , der Schwesterpublikation von JavaWorld

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

  • Nick Petreleys Kommentar zur Sun / MS-Klage, ebenfalls in NC World

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

Diese Geschichte: "Was bedeutet die Klage von Sun gegen Microsoft für Java-Entwickler?" wurde ursprünglich von JavaWorld veröffentlicht.