Que signifie le procès de Sun contre Microsoft pour les développeurs Java?

7 octobre 1997 - Sun a répondu à la sortie d'Internet Explorer (IE) 4.0 par Microsoft et à sa version 2.0 du SDK pour Java (SDKJ) par une action en justice devant le tribunal de district américain. Selon le communiqué de presse de Sun, "la plainte accuse Microsoft de contrefaçon de marque, de publicité mensongère, de rupture de contrat, de concurrence déloyale, d'ingérence dans un avantage économique potentiel et d'incitation à la rupture de contrat". Plus précisément, Microsoft a fait le choix la semaine dernière d'expédier des produits qu'il prétend être entièrement compatibles Java 1.1, mais qui n'ont pas réussi les tests de compatibilité Java 1.1 que la société a reçus de Sun en février. "Microsoft s'est engagé dans une démarche délibérée pour fragmenter Java", a déclaré Alan Baratz, président de JavaSoft, lors d'une téléconférence Sun aujourd'hui à 10h30 PST.

Du point de vue du développeur, qu'est-ce que cela signifie? Eh bien, tout d'abord, si vous créez quelque chose avec le JDK 1.1 de Sun (ou avec l'environnement certifié Java 1.1 d'une autre société, telle qu'IBM, Borland et Symantec), il risque de ne pas fonctionner sous IE 4.0. En outre, si vous créez quelque chose avec l'environnement de développement de Microsoft, il se peut qu'il ne s'exécute pas dans un environnement Java 1.1 non Microsoft. Plus précisément, Microsoft ne prend pas en charge les interfaces Java Native (JNI) ou l'invocation de méthode à distance (RMI), et il a modifié les bibliothèques de classes Core Java avec environ 50 méthodes et 50 champs qui ne font pas partie des interfaces de programmation d'applications Java publiques ( API) publié par Sun.

JNI et RMI: pourquoi le rejet par Microsoft de ceux-ci pose un problème

JNI est l'interface de code native utilisée pour accéder aux fonctionnalités spécifiques à la plate-forme, comme un port série ou un microphone, pour des éléments qui ne sont pas encore disponibles via l'API principale. L'objectif de JNI est de permettre aux développeurs de fournir un ensemble unique de bibliothèques natives pour chaque implémentation Java sur une plate-forme spécifique.

Microsoft a décidé de prendre en charge sa propre interface, appelée RNI, qui offre les mêmes fonctionnalités que JNI. En ne prenant pas en charge JNI, Microsoft oblige les développeurs à fournir différentes bibliothèques pour les utilisateurs de machines virtuelles Java (JVM) Microsoft et non Microsoft. Il n'y a rien de mal à soutenir RNI par Microsoft si l'entreprise pense que sa technologie est meilleure. Cependant, en ne prenant pas en charge JNI, Microsoft ne peut pas affirmer que IE 4.0 est entièrement compatible Java 1.1.

RMI fournit un moyen d'exécuter du code Java sur des machines virtuelles Java étrangères. Il est fréquemment comparé aux appels de procédure distante (RPC), à l'architecture CORBA (Common Object Request Broker) et au modèle d'objet de composant distribué (DCOM), en fonction de l'arrière-plan de la personne qui parle. Microsoft affirme qu'il prend en charge DCOM au lieu de RMI car RMI ne prend pas en charge les communications Java vers non Java. Le but spécifique de l'utilisation de RMI est les communications système Java-Java. Par exemple, avec RMI, vous pouvez appeler des méthodes d'objets existant dans d'autres machines virtuelles Java, sans connaître le type de classe, tout en préservant la sécurité d'exécution de Java.

Si vous avez besoin de sortir des communications Java-Java, CORBA est en fait la solution portable, pas DCOM. Pourquoi? DCOM est orienté vers le monde Microsoft, ne devenant disponible que récemment pour le monde Unix avec des produits comme EntierX de Software AG. Si vous avez besoin d'utiliser RMI, Internet Explorer n'est évidemment pas une option disponible. Si vous avez besoin de communications système Java vers non Java, pour s'interfacer avec des systèmes hérités (non Java) qui reposent sur CORBA, Netscape Communicator 4.0 est livré avec l'ORB VisiBroker de Visigenic. (Pour la prise en charge RMI avec Netscape Communicator, vous devez utiliser une version bêta d'un correctif de navigateur, car Communicator ne prétend pas être un navigateur Java 1.1.)

Rotten to the Core Java API: le nœud du problème

Le dernier problème d'incompatibilité Java 1.1 identifié est en fait le plus effrayant. Il est facile d'éviter RMI et JNI si votre application le permet: vous ne les utilisez tout simplement pas. Le point de friction est que Microsoft a décidé que les bibliothèques de classes Core Java étaient insuffisantes pour ses besoins. Maintenant, il n'y a rien de mal à étendre les choses en sous-classant et en plaçant les nouveaux objets dans un package en dehors de la hiérarchie de classe java. *. Mais décider d'ajouter environ 50 méthodes et 50 champs dans les classes des packages java.awt, java.lang et java.io, comme l'a fait Microsoft, est extrêmement problématique. "Microsoft a faussement modifié les classes clés et les a insérées dans leur SDK", a déclaré Baratz, ce qui fait que les développeurs pensent qu'ils écrivent Java, alors qu'en réalité ils écrivent quelque chose qui ne fonctionne que sur Internet Explorer.

Comment les ajouts de Microsoft aux classes affectent-ils les développeurs Java? Eh bien, si vous comptez sur ces changements, ou si vous les utilisez simplement par inadvertance, votre programme ne fonctionnera que dans le système Java de Microsoft. De plus, si vous créez un programme en dehors de l'environnement de développement de Microsoft, il attendra une certaine API principale. Malheureusement, cette API principale est différente de celle de l'environnement Microsoft, de sorte que le programme peut ne pas y fonctionner. Le test de la suite de compatibilité qui a signalé ce problème est ce qu'on appelle un signature test.

Par exemple, si la méthode foo()est supposée accepter un paramètre de type bar, il vaut mieux obtenir un objet de type bar. Si quelqu'un veut que vous passiez un objet de type à la bazplace, cela ne fonctionnera que sur les systèmes qui ont changé le noyau pour l'accepter. Et, Microsoft a introduit ce changement. Maintenant, Microsoft peut penser qu'il s'agit de l'implémentation de référence de Java pour Windows. Mais le fait est que seul Sun peut apporter des modifications à l'API Core Java. Oui, tout titulaire de licence peut demander des modifications, et beaucoup le font fréquemment. Mais Microsoft a décidé à lui seul et sans autorisation de changer ces choses.

En fin de compte, le but du procès est, selon les termes de Baratz, "de remettre Microsoft en conformité", et le plus rapidement possible. Mais jusqu'à ce que les légalités soient résolues, Sun refusera à Microsoft toutes les améliorations technologiques Java en cours, telles que la nouvelle machine virtuelle Java 2.0 appelée HotSpot. Si Microsoft ne revient pas en conformité avec Java, il devra proposer une implémentation en salle blanche de sa version de quelque chose qui ne s'appellera pas Java - c'est-à-dire s'il veut faire quelque chose avec l'équivalent des bytecodes Java. Qui sait ce qu'il adviendra d'IE 4.0, du SDK pour Java 2.0 et du prochain Visual J ++?

Paroles de sagesse: que le développeur Java se méfie

En tant que développeur, vous devrez faire très attention. Si vous décidez d'utiliser les environnements de développement de Microsoft et que vous devez créer des solutions multiplates-formes, familiarisez-vous avec les API Java Core. Vous devrez éviter tout ce qui ne fait pas partie des spécifications publiques. Jusqu'à ce qu'une liste complète des éléments incompatibles soit publiée, il incombera aux développeurs individuels de savoir ce qui est compatible ou non. Bien sûr, si vous ne vous souciez pas de «l'écriture unique, exécutez n'importe où», vous pouvez utiliser les capacités spécifiques à la plate-forme de Microsoft. Il est toutefois possible que la licence Java de Microsoft soit révoquée. Sun tente déjà de révoquer la capacité de Microsoft à afficher le logo compatible Java.

John Zukowski est un Software Mage avec MageLang Institute, auteur de Java AWT Reference de O'Reilly & Associates et Borland's JBuilder: Aucune expérience requise de Sybex, ainsi que du guide Focus on Java de la société minière.

En savoir plus sur ce sujet

  • Communiqué de presse de Sun Microsystems

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

  • FAQ de Microsoft expliquant pourquoi il ne prend pas en charge RMI / JNI, etc.

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

  • Prise en charge actuelle de Java par Netscape dans Communicator 4.0

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

  • Voir l'histoire d'Elizabeth Heichler, de News Service, et de Bob McMillan, SunWorld

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

  • Notre propre Jenni Aloi a écrit une histoire sur la colère du Java Lobby envers Microsoft

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

  • L'histoire de CNet sur le procès Sun contre Microsoft

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

  • San Jose Mercury News sur le procès

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

  • Microsoft devrait-il être autorisé à modifier les bibliothèques de classes clés de Java? Participez à notre dernier sondage

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

  • Une revue des outils de développement Java neutres pour les plates-formes dans NC World , la publication sœur de JavaWorld

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

  • Commentaire de Nick Petreley sur le procès Sun / MS, également dans NC World

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

Cette histoire, "Que signifie le procès de Sun contre Microsoft pour les développeurs Java?" a été initialement publié par JavaWorld.