Sun, Microsoft und Java: Ansichten eines Insiders

ZDNet: Java löste also einige Interoperabilitätsprobleme. Aber Microsoft ist mit .NET seinen eigenen Weg gegangen, was im Prinzip zu einem Interoperabilitätsproblem auf höherer Ebene geführt hat. Sehen Sie eine Möglichkeit .NET und Java zu einer Technologie zu verschmelzen?

Gosling: In gewisser Hinsicht ist dies genau das, was Web Services tun. Sie stellen eine Brücke dar. Aber man kann zwei Dinge nicht miteinander verbinden, die sich hartnäckig dagegen wehren. Bei Microsoft gehört es zur Unternehmenspolitik, anders zu sein. Sie wollen anders sein. Tatsächlich waren sie anfangs sechs Monate oder sogar ein Jahr lang sehr engagierte und nette Mitglieder der Java-Community, aber dann haben sie es sich doch anders überlegt.

ZDNet: War das 1995 oder 1996?

Gosling: Das müsste 1996 gewesen sein, glaube ich. Aber wenn man zusammenarbeitet, muss man an der Zusammenarbeit auch Interesse haben. Für Microsoft ist das ein ziemlich langer Lernprozess. Sie mögen das einfach nicht. Aber langsam tut sich da etwas. Wir bemühen uns sehr um eine Zusammenarbeit mit Microsoft, aber es bleibt ein etwas distanziertes Verhältnis. Wir kümmern uns gemeinsam um Schnittstellen, Web Services und Interoperabilität.

In C muss man über die Identität von Dingen lügen können. In Java ist dies absolut verboten.


ZDNet: Kann man Programme, die für .NET in C# geschrieben wurden, in eine Java Virtual Machine einspeisen?

Gosling: Die einzige ernsthafte Differenz ist dieser unsichere Modus, den Microsoft viel verwendet. Eines der Prinzipien, von denen ich überzeugt bin, besagt, dass es keinen unsicheren Modus geben sollte.

ZDNet: Was meinen Sie mit unsicher?

Gosling: Microsoft unterscheidet zwischen Managed Code und Unmanaged Code. Managed Code ist die Variante, bei der man auch Aussagen über die Sicherheit und Zuverlässigkeit machen kann. Aber mit Unmanaged Code kann man sich auf nichts mehr verlassen. Speicherbeschädigungen lassen sich nicht mehr von korrektem Verhalten unterscheiden. Es ist ziemlich schwierig, zu analysieren, was ein Programm macht. C-Programme (eine Art von Unmanaged Code) tendieren dazu, auf geheimnisvolle Weise auszufallen. Letztlich geht es um die entscheidende Frage, wie Sicherheitsmechanismen funktionieren. In C muss man über die Identität von Dingen lügen können. In Java ist dies absolut verboten.

ZDNet: Was müsste passieren, um Microsoft zur Teilnahme am Java Community Process (JCP) zu bewegen?

Gosling: Ich habe keine Ahnung. Am besten fragen Sie Sun-CTO Greg Papadopoulos.

ZDNet: Würden Sie gern wieder so eine Situation haben wie in diesen sechsmonatigen „Flitterwochen“?

Gosling: Ich würde mich freuen, wenn Microsoft mit der übrigen JCP-Community zusammenarbeiten würde.

ZDNet: Sie haben gerade über das Glass Fish-Projekt Suns Java Application Server als Open-Source-Software veröffentlicht. Wollen Sie damit Erfahrungen sammeln, die Sie eventuell auf die Veröffentlichung der Java Standard Edition (die Grundlage von Java) als Open-Source-Software anwenden können?

Gosling: Vielleicht. Fast alles, was im Rahmen der Java SE geschieht, ähnelt stark einem Open-Source-Projekt. Der Hauptunterschied ist unsere Lizenz, die Tests zur Vorbedingung macht. Wenn wir uns Umgebungen anschauen, wo Java extensiv zum Einsatz kommt, wird die gesamte Test-Frage zu einem wirklich großen Problem. Da sind all die Leute der Open-Source-Community, die einerseits sagen: „Wir testen ja, aber wir wollen dazu nicht zwingend verpflichtet werden.“ Es ist durchaus vorstellbar, dass Java SE eines Tages als Open-Source-Software veröffentlicht wird. Eine Menge hängt davon ab, wie bequem die Community wird.

Der große Unterschied zwischen den letzten fünf Jahren und den ersten fünf Jahren besteht darin, dass Java inzwischen Bestandteil vieler riesiger, unternehmenskritischer Systeme geworden ist.


Es gibt viele negative Beispiele, die uns ziemlich nervös machen. Man schaue sich einmal die Erfahrungen der Leute mit Javascript an (einer Sprache für fortschrittliche Webseiten, die nichts mit Java zu tun hat). Dort gibt es Probleme mit der Interoperabilität zwischen all den unterschiedlichen Varianten von Javascript, die den Webdesignern Albträume bereiten. Soll der Code auf diesem Browser funktionieren, muss man es so machen. Soll er auf einem anderen Browser laufen, muss man es so machen. Leute aus der Java-Welt werfen einen Blick in die Javascript-Handbücher und wenden sich mit Schaudern ab.

Themenseiten: Anwendungsentwicklung, Plattform, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Sun, Microsoft und Java: Ansichten eines Insiders

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *