Cosa significa per gli sviluppatori Java la causa di Sun contro Microsoft?

7 ottobre 1997 - Sun ha risposto al rilascio di Microsoft di Internet Explorer (IE) 4.0 e alla sua versione 2.0 dell'SDK per Java (SDKJ) con una causa presso il tribunale distrettuale degli Stati Uniti. Secondo il comunicato stampa di Sun, "la denuncia accusa Microsoft di violazione del marchio, falsa pubblicità, violazione del contratto, concorrenza sleale, interferenza con un potenziale vantaggio economico e induzione di violazione del contratto". In particolare, la scorsa settimana Microsoft ha scelto di spedire prodotti che dichiara essere completamente conformi a Java 1.1, ma che non sono riusciti a superare i test di compatibilità con Java 1.1 che l'azienda ha ricevuto da Sun a febbraio. "Microsoft ha intrapreso una condotta deliberata per frammentare Java", ha detto Alan Baratz, presidente di JavaSoft, durante una teleconferenza Sun oggi alle 10:30 PST.

Dal punto di vista di uno sviluppatore, cosa significa? Innanzitutto, se crei qualcosa con Sun's 1.1 JDK (o con l'ambiente certificato Java 1.1 di un'altra società, come IBM, Borland e Symantec), potrebbe non funzionare con IE 4.0. Inoltre, se si crea qualcosa con l'ambiente di sviluppo di Microsoft, potrebbe non essere eseguito in un ambiente Java 1.1 non Microsoft. In particolare, Microsoft non supporta Java Native Interfaces (JNI) o Remote Method Invocation (RMI) e ha alterato le librerie di classi Core Java con circa 50 metodi e 50 campi che non fanno parte delle Java Application Programming Interfaces pubbliche ( API) pubblicato da Sun.

JNI e RMI: Perché il rifiuto da parte di Microsoft di questi pone un problema

JNI è l'interfaccia del codice nativo utilizzata per accedere a funzionalità specifiche della piattaforma come una porta seriale o un microfono, per cose che non sono ancora disponibili tramite l'API principale. L'obiettivo di JNI è consentire agli sviluppatori di fornire un unico set di librerie native per ogni implementazione Java su una piattaforma specifica.

Microsoft ha deciso di supportare la propria interfaccia, chiamata RNI, che fornisce le stesse funzionalità di JNI. Non supportando JNI, Microsoft obbliga gli sviluppatori a fornire diverse librerie per utenti JVM (Java virtual machine) Microsoft e non Microsoft. Non c'è niente di sbagliato nel supporto di Microsoft a RNI se la società pensa che la sua tecnologia sia migliore. Tuttavia, non supportando JNI, Microsoft non può affermare che IE 4.0 è completamente conforme a Java 1.1.

RMI fornisce un mezzo per eseguire codice Java su Java virtual machine esterne. Viene spesso confrontato con RPC (Remote Procedure Calls), CORBA (Common Object Request Broker Architecture) e DCOM (Distributed Component Object Model), a seconda del background della persona che parla. Microsoft afferma di supportare DCOM anziché RMI perché RMI non supporta le comunicazioni da Java a non Java. Lo scopo specifico dell'utilizzo di RMI è per le comunicazioni di sistema Java-Java. Ad esempio, con RMI, è possibile richiamare metodi di oggetti esistenti in altre Java virtual machine, senza conoscere il tipo di classe, preservando la sicurezza del runtime di Java.

Se è necessario spostarsi al di fuori delle comunicazioni Java-to-Java, CORBA è effettivamente la soluzione portatile, non DCOM. Perché? DCOM è orientato al mondo Microsoft, solo di recente è diventato disponibile per il mondo Unix con prodotti come InteraX di Software AG. Se è necessario utilizzare RMI, ovviamente Internet Explorer non è un'opzione disponibile. Se hai bisogno di comunicazioni di sistema da Java a non Java, per interfacciarti con sistemi legacy (non Java) che si basano su CORBA, Netscape Communicator 4.0 viene fornito con VisiBroker ORB di Visigenic. (Per il supporto RMI con Netscape Communicator, è necessario utilizzare una versione beta di una patch del browser, poiché Communicator non dichiara di essere un browser Java 1.1.)

Rotten to the Core Java API: The nocciolo del problema

L'ultimo problema di incompatibilità di Java 1.1 identificato è in realtà il più spaventoso. È facile evitare RMI e JNI se la tua applicazione lo consente: semplicemente non li usi. Il punto critico è che Microsoft ha deciso che le librerie di classi Core Java erano insufficienti per le sue esigenze. Ora non c'è niente di sbagliato nell'estendere le cose creando sottoclassi e inserendo i nuovi oggetti in un pacchetto al di fuori della gerarchia di classi java. *. Ma decidere di aggiungere circa 50 metodi e 50 campi nelle classi all'interno dei pacchetti java.awt, java.lang e java.io, come ha fatto Microsoft, è estremamente problematico. "Microsoft ha alterato in modo ingannevole le classi chiave e le ha inserite nel proprio SDK", ha affermato Baratz, il che porta gli sviluppatori a pensare di scrivere Java, mentre in realtà stanno scrivendo qualcosa che funziona solo su Internet Explorer.

In che modo le aggiunte di Microsoft alle classi influenzano gli sviluppatori Java? Bene, se ti affidi a queste modifiche o le usi inavvertitamente, il tuo programma funzionerà solo all'interno del sistema Java di Microsoft. Inoltre, se crei un programma al di fuori dell'ambiente di sviluppo Microsoft, si aspetterà una determinata API di base. Sfortunatamente, quell'API principale è diversa da quella all'interno dell'ambiente Microsoft, quindi il programma potrebbe non funzionare lì. Il test della suite di compatibilità che ha segnalato questo problema è quello che viene chiamato a signature test.

Ad esempio, se foo()si suppone che il metodo accetti un parametro di tipo bar, è meglio ottenere un oggetto di tipo bar. Se qualcuno invece vuole che tu passi un oggetto di tipo baz, funzionerà solo su quei sistemi che hanno cambiato il core per accettarlo. E Microsoft ha introdotto questo cambiamento. Ora, Microsoft potrebbe pensare che sia l'implementazione di riferimento di Java per Windows. Ma il fatto è che solo Sun può introdurre modifiche all'API Core Java. Sì, qualsiasi licenziatario può chiedere modifiche e molti lo fanno spesso. Ma Microsoft da sola e senza autorizzazione ha deciso di cambiare queste cose.

Alla fine, l'obiettivo della causa è, nelle parole di Baratz, "riportare Microsoft in conformità" e il più rapidamente possibile. Ma fino a quando le questioni legali non saranno risolte, Sun tratterrà da Microsoft tutti i miglioramenti in corso della tecnologia Java, come la nuova macchina virtuale Java 2.0 chiamata HotSpot. Se Microsoft non torna in conformità con Java, dovrà trovare un'implementazione in camera bianca della sua versione di qualcosa che non si chiamerà Java, cioè se vuole fare qualcosa con l'equivalente di bytecode Java. Chissà cosa accadrà a IE 4.0, all'SDK per Java 2.0 e al prossimo Visual J ++?

Parole di saggezza: fate attenzione allo sviluppatore Java

Come sviluppatore, dovrai procedere con molta attenzione. Se decidi di utilizzare gli ambienti di sviluppo Microsoft e hai bisogno di creare soluzioni multipiattaforma, acquisisci familiarità con le API Core Java. Dovrai evitare tutto ciò che non fa parte delle specifiche pubbliche. Fino a quando non verrà pubblicato un elenco completo di elementi incompatibili, spetterà ai singoli sviluppatori sapere cosa è e cosa non è compatibile. Naturalmente, se non ti interessa "scrivi una sola volta, esegui ovunque", puoi utilizzare le funzionalità specifiche della piattaforma di Microsoft. È possibile, tuttavia, che la licenza Java di Microsoft venga revocata. Sun sta già tentando di revocare la capacità di Microsoft di visualizzare il logo compatibile con Java.

John Zukowski è un Software Mage del MageLang Institute, autore di Java AWT Reference di O'Reilly & Associates e JBuilder di Borland: Nessuna esperienza richiesta da Sybex, nonché della guida Focus on Java presso la Mining Company.

Ulteriori informazioni su questo argomento

  • Comunicato stampa di Sun Microsystems

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

  • Domande frequenti di Microsoft sul motivo per cui non supporta RMI / JNI e così via

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

  • L'attuale supporto di Netscape per Java in Communicator 4.0

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

  • Guarda la storia di Elizabeth Heichler, di News Service, e Bob McMillan, SunWorld

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

  • La nostra Jenni Aloi ha scritto una storia sulla rabbia della Java Lobby nei confronti di Microsoft

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

  • La storia di CNet sulla causa Sun contro Microsoft

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

  • San Jose Mercury Notizie sulla causa

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

  • Microsoft dovrebbe essere autorizzato a modificare le librerie di classi chiave di Java? Partecipa al nostro ultimo sondaggio

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

  • Una revisione degli strumenti di sviluppo Java indipendenti dalla piattaforma in NC World , la pubblicazione sorella di JavaWorld

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

  • Il commento di Nick Petreley sulla causa Sun / MS, anche in NC World

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

Questa storia, "Cosa significa per gli sviluppatori Java la causa di Sun contro Microsoft?" è stato originariamente pubblicato da JavaWorld.