microsoft.public.fr.jpp

Long-form reference · 8,960 words · about a 39-minute read

The three messages this group left behind

The Internet Systems Consortium mirrors Usenet's control traffic group by group, and its file for this name is two kilobytes long. It contains three articles and nothing else. The first is a newgroup message dated Monday 28 August 2000 at 09:28:22 Pacific time, sent from the operations mailbox [email protected], injected from a Microsoft posting host, and carrying the two lines that such a message is meant to carry: the words For your newsgroups file, and the bare name with no description after it. The second is an identical newgroup message dated Monday 27 November 2000 at 10:39:59 Pacific time. The third has not been described on this page before, and it is the one that settles the group's fate.

It is a removal. On Monday 10 January 2005 at 15:42:54 Pacific time, the same operations address sent an rmgroup control article for microsoft.public.fr.jpp. The message has a header block, a Lines: 1 count, and no body at all: no reason, no replacement, no forwarding address. That is the entire documentary life of this group as the control channel records it — created, reissued three months later, removed four years and some months after that, all three times by the same automated tool at the same company, and never once accompanied by a sentence of explanation.

The consequence is visible in the catalogue that news administrators load today. The consortium distributes a master newsgroups file pairing each name with a one-line description, and an active file listing the names a server may carry. Both are checkable, and both were checked for this page. The newsgroups file currently holds 45,003 names, of which 1,770 begin microsoft. and 103 begin microsoft.public.fr. — and microsoft.public.fr.jpp is not among them. Nor is it in the active file. The only line in either file containing the letters jpp is an unrelated piece of alt.* debris. This group is one of the comparatively rare entries in this directory whose name has been genuinely retired from the namespace rather than merely abandoned in it: the removal of January 2005 was honoured, and the name is gone.

That is worth saying plainly because the usual pattern in this hierarchy is the opposite one. Names outlive their subjects here by decades; a removal request is only a request, and administrators routinely ignored them. The French branch's own archive records thirty-four French names removed in a single day in November 2001 by a volunteer in Ontario countering a run of forged creations; seventeen of those thirty-four are still in the master list a quarter of a century later. The French Visual J++ room is not in that company. Somebody asked for it to go, and the network agreed.

Twenty-one names in three seconds

The creation message is best read against its neighbours. Reading all 163 archived control files for names beginning microsoft.public.fr. — the exercise the French-branch page describes — puts 310 control articles in date order, and 28 August 2000 turns out to be one of the branch's busy days. Twenty-one French newgroup messages went out in three seconds, between 09:28:21 and 09:28:23 Pacific time, with a twenty-second name following at 11:48. The three-second burst reads like a catalogue page: backoffice, exchange, office, powerpoint, proxy, publisher, siteserver, sna and windowsme in the first second; devasp, devxml, ie, jpp, sms, ssafe, vinterdev and vstudio in the second; accessoires, devdhtml, jeuxmicrosoft and windowsmedia in the third.

The middle second is the developer second, and it is the most informative line of paperwork this group has. France was given rooms for Active Server Pages, for XML, for the browser, for Systems Management Server, for Visual SourceSafe, for Visual InterDev, for Visual Studio and for Visual J++ in one machine-generated breath. Whoever drew up that list was working through a product line rather than responding to demand: the French Visual J++ room was not created because francophone developers had asked for it, but because Visual J++ was on the list of things Microsoft sold and the list was being transcribed into a namespace.

The timing is the part that repays a second look. Visual J++ 6.0 had shipped almost exactly two years earlier and would never be succeeded. The preliminary injunction restricting its compiler was twenty-one months old. The Ninth Circuit had vacated that injunction the previous August, the district court had reinstated part of it in January 2000 on a different legal footing, and the settlement that would end the case was five months away. France received its Visual J++ newsgroup at the point in the product's life when the product had stopped moving and the litigation had not.

The November reissue is the branch-wide event the page above already mentions, and the figures are these. On 27 November 2000 the French files record 63 control articles, all of them newgroup messages and not one of them a removal, fired off in a window that runs from 10:39:57 to 10:40:00 Pacific time. This group's message sits at 10:39:59, in a tranche of twenty names that also carried frontpage, ie, ie4, ie5, iis, inetexplorer.ie5, jeuxmicrosoft, money, office, outlook, outlookexpress, photodraw, pocketpc, powerpoint, project, proxy, publisher, sbs and siteserver. Reissuing was housekeeping rather than policy: a control message is a request that every administrator answers privately by configuration, and sending it again improves a name's odds of being carried. The hierarchy's habit of creating and closing groups by fiat, without discussion, vote or charter, is set out on the microsoft.public.* hierarchy page.

The removal of January 2005 was also part of a sweep, and its membership is the most eloquent thing in the file. Five French names were removed that afternoon, in the seven minutes between 15:42:07 and 15:48:43: SNA Server, Visual J++, Internet Explorer 4, the Visual Studio .NET beta room, and BackOffice. Every one of them names a product that had been superseded, withdrawn or discontinued. This was a tidying of dead shelves, and the room for Microsoft's Java product was on the same shelf as the room for a 1997 browser and the room for a beta that had shipped.

The problem of a name with two plus signs

The leaf jpp is a workaround, and the thing it works around is a typographical accident. The product was called Visual J++, and Usenet group names do contain plus signs — 168 of the 45,003 names in the current master file have at least one, from comp.lang.c++ downwards — but they sit awkwardly in configuration files, in shell commands, in regular expressions and in the era's newsreaders. The French branch solved the problem by spelling the plus signs out: J, plus, plus. It is the only name in the French branch that does so, and the joke, such as it is, survives being explained.

Other branches solved it differently, and the control archive records all three solutions. The Spanish and Japanese branches were each given a room called visualj, with the plus signs simply dropped. The Spanish one was created on 12 September 2000, withdrawn four seconds later, created again a minute after that, reissued in the November sweep and finally removed in December 2009; the Japanese one appears in the same 27 November 2000 reissue as this group and was removed on 14 October 2004. Microsoft also tried, briefly, to mint a plus-free English name. On 5 June 2000 a group called microsoft.public.visualj was created at 10:42, removed at 10:44, created again at 10:54, removed again at 10:59, and created a third time at 12:56, only to be removed for good the following morning. A family of five subordinate names — compiler, com-support, debugger, dev-environment and installation — was swept away inside two seconds on 22 June 2000. Whatever was being attempted that month, it was abandoned inside three weeks.

What the English-language reader actually had, and still has, is a family that kept its plus signs. The current master newsgroups file lists microsoft.public.java.visualj++ together with four children — build.package.deploy, debugger, dev.environment and wfc.general — and, separately, microsoft.public.visualj++.migration. Six catalogued English rooms for one discontinued product; one French room, now deleted. No archived control file could be found for any of the six, which is the ordinary condition of a great many names in this hierarchy and proves nothing about how they were created; it does mean that no removal for them is on record, which is why they are still in the file and this group is not.

There is a small comic footnote in the descriptions. The one-line descriptions in that file were generated by family rather than written by group, and the generator does not cope with punctuation: microsoft.public.visualj++.migration is described in the master catalogue as a Microsoft Visual J newsgroup, the product's name silently amputated. The five visualj++ rooms under the java branch fare no better; each is described, uninformatively and identically, as a Microsoft Java newsgroup. The same mechanism is what left this group's French neighbours with descriptions that do not distinguish them from their parents, a subject the French-branch page treats at length.

Visual J++: what the product actually was

Visual J++ was Microsoft's implementation of the Java programming language and, in the same breath, the name of the development environment that came with it. Reference accounts date the debut of version 1.0 to the autumn of 1996 — the trade press announced it on 1 October of that year and Dr Dobb's Journal reviewed it that December — which places it roughly a year and a half after Java's public arrival and inside the same twelve months as the first Microsoft virtual machine.

Version 1.1 was folded into Visual Studio 97, announced in January 1997 and unveiled publicly that March: the first time Microsoft bundled its language tools into a single suite rather than selling Visual Basic, Visual C++, Visual FoxPro and Visual SourceSafe separately. Visual J++ had in fact been one of the products that already used the shared environment then called Developer Studio, which is part of why the bundle made sense. Version 6.0 arrived with Visual Studio 6.0 — unveiled at Tech-Ed in June 1998, generally available from 2 September 1998 — and there the version numbers stop. Visual Studio 6.0 was the last release of the suite to contain Visual J++, and 6.0 was the last version of Visual J++ there ever was. When France was given a room for the product in August 2000, the product had been frozen for two years.

Three parts made up the whole, and the litigation touched all three separately. There was a compiler, which turned Java source into class files. There was a virtual machine, which ran them, and which reached most of its users not as a developer tool at all but as a component of a web browser. And there was the environment: an integrated development system, with an editor, a debugger, project and build management, and — from version 6.0 — a designer for building Windows user interfaces.

That last part rested on a class library called the Windows Foundation Classes, or WFC, which wrapped the Win32 platform interface and the browser's dynamic-HTML object model into a single set of classes, aimed principally at building graphical interfaces for Java applications on Windows. WFC is the clearest statement of what the product was for. A Java class library that encapsulates Win32 is not a portability layer; it is the opposite of one. It let a Java programmer write a Windows application in Java quickly and well, and the applications so written ran on Windows.

The same orientation shows in the package names that survive in the product's documentation and sample code — com.ms.ui for the interface classes, com.ms.win32 for the platform calls, com.ms.activeX for driving ActiveX controls from Java. None of those were part of anybody's Java specification. All of them were extremely convenient if the machine on the desk ran Windows, and useless otherwise.

The virtual machine that came with the browser

The Microsoft Java Virtual Machine was first made available for Internet Explorer 3, released on 13 August 1996, so that users could run applets while browsing. That distribution channel matters more than any developer-tool figure: for several years the most widely installed Java runtime on Windows desktops was not a product anyone had chosen, but a component of a browser that shipped with the operating system. A developer writing an applet in 1998 could reasonably assume that whatever a Windows visitor had, it was Microsoft's.

By the standard reference accounts it was, for the first two years after its release, the fastest Windows implementation of a Java virtual machine; it took PC Magazine Editors' Choice awards in 1997 and 1998 for best Java support; and the claim of primacy was contested by IBM in 1999, whose implementation beat both Microsoft's and Sun's in one widely cited benchmark. Speed was not incidental to the dispute. A fast, ubiquitous, incompatible runtime is a much harder problem for a compatibility regime than a slow one, because developers have a reason to target it.

One point in the published accounts sits awkwardly against the court record and is worth flagging rather than smoothing over. A widely reproduced summary states that a 1998 release of the Microsoft virtual machine added support for Sun's Java Native Interface alongside Microsoft's own native interfaces. The district court, in November 1998, found that Microsoft's runtime interpreters did not support that interface, and made supporting it the first substantive requirement of its injunction. Both statements cannot be describing the same software on the same date. This page reports the court's finding as the court stated it, and notes the discrepancy without attempting to resolve it.

The runtime's later career is a footnote to the settlements rather than to the product. The initial release of Windows XP in 2001 shipped without any Java virtual machine at all, a consequence of the settlement reached that January; users who wanted applets had to fetch either Sun's runtime or Microsoft's. Service Pack 1, released on 9 September 2002, put the Microsoft virtual machine back in the box.

Write once, run anywhere: what the phrase required

The slogan attached to Java from the beginning promised that a program written once would run wherever a virtual machine existed. It is worth being precise about what that promise actually depends on, because the whole dispute is contained in the precision. It does not depend on the language being good, or the runtime being fast, or the vendor being generous. It depends on every implementation accepting the same programs and running them the same way — which means that an implementation must be complete, providing everything the specification requires, and unextended, providing nothing the specification does not.

Either failure breaks it, and breaks it asymmetrically. An implementation that omits a required feature makes portable programs fail on that machine. An implementation that adds an unrequired feature makes programs written for that machine fail everywhere else — and does so silently, because nothing warns the programmer that the convenience they have just used is local. The second failure is the more corrosive of the two, because its cost falls on people who never chose it.

The specification's own preface said as much, in words the Ninth Circuit later quoted: the aim was that the behavior of every language construct [be] specified, so that all implementations of Java will accept the same programs. The language definition backed this up structurally by closing its list of keywords. Java's specification enumerated its keywords exhaustively and reserved exactly two words — const and goto — without giving them any meaning, precisely so that later versions could claim them. A list built that way is not merely a list; it is a statement that additions are the specifier's business and nobody else's. The appellate court drew that inference explicitly, holding that the specification implicitly prohibits the addition of keywords by defining a complete list of keywords and then reserving only two words for later inclusion.

The commercial arrangement between the two companies tried to turn that architectural point into a contractual one. In March 1996 Sun and Microsoft signed a Technology License and Distribution Agreement under which Microsoft paid $3.75 million a year for broad rights to make, use, modify, adapt and create derivative works of the technology in source form, and to distribute it in binary form as part of a product. Against those rights the agreement set compatibility requirements: section 2.6(a)(iv) obliged Microsoft to produce a compatible implementation within six months of any significant upgrade by Sun; section 2.6(a)(vi) obliged it to make available only compatible implementations; and section 2.6(b)(iv) required that any Java compiler Microsoft shipped include a mode which a Tool Customer may use to permit such Product to pass the Java Language Test Suite accompanying an upgrade. Compatibility itself was defined by reference to a set of largely automated tests Sun had written.

That drafting is the hinge of everything that followed, and the Ninth Circuit's opening sentence is the fairest summary anyone has written of it: This case illustrates how fast technology can outdistance the capacity of contract drafters to provide for the ramifications of a computer software licensing arrangement. The agreement had been negotiated in a hurry in 1996. Within a year both companies believed they had improved Java, and the contract had to be asked which of them was allowed to.

The extensions: two keywords and three directives

The court record is unusually specific about what was added, and the specificity is the point: this was not a vague charge of divergence but a list of five named things. The appellate court's formulation was that Microsoft modified the Java compiler by adding an extended mode that includes two keyword extensions and three compiler directives that enable programmers to use some Windows features and to program more efficiently in the Windows environment.

The three directives were @dll, @com and @security. The first two supported Microsoft's native-code mechanisms — J/Direct and Java/COM respectively — letting a developer reach straight into a Windows dynamic-link library or a Component Object Model library from Java source. The third disabled certain security facilities implemented in the Microsoft virtual machine. The delivery mechanism was ingenious and, from a compatibility point of view, sly: a developer wrote these directives into documentation comments, the kind of comment a compiler normally ignores entirely. Microsoft's compiler, in its extended mode, read them. Any other compiler read a comment. The district court noted Microsoft's answer to the charge — that Sun's own tooling recognised a directive called @deprecated in the same position — and recorded the distinction Sun drew, which was that the deprecated attribute does not affect the behaviour of the resulting class file.

The two keywords were delegate and multicast. The court described them as used in a class declaration to create method pointers, and as designed to handle the problem of event handling — the everyday business of saying which piece of code should run when a button is clicked. When the compiler met them in extended mode it emitted class files whose attributes referenced two classes Microsoft had written, com.ms.lang.Delegate and com.ms.lang.MulticastDelegate. A virtual machine without those classes cannot run the result. The district court put the consequence in one sentence that is worth having verbatim: a developer's use of the keyword extensions in its source code will generate errors with a non-Microsoft compiler, and the compiled output cause the virtual machine to look for classes which only Microsoft's virtual machine possesses.

Two properties of that arrangement made it contentious out of proportion to its size. The first is that it was genuinely useful. Event handling in Java of that period was done with inner classes, which are verbose; a bound method reference is shorter and reads better, and programmers notice such things. The second is that the resulting incompatibility was invisible at the moment of writing. Nothing in the source said this file is now Windows-only. The class file said it, silently, to whatever machine later refused to run it.

The omissions: JNI, RMI and the missing halves

The other half of the charge was subtraction, and it is the half that is usually forgotten. Java could never do everything on its own; when a program needed the machine underneath it, part of the program had to be written in a platform language such as C, and something had to join the two. Sun's mechanism for that was the Java Native Interface, which did not yet exist when the 1996 licence was signed and which the district court treated as a permissible upgrade to the licensed technology. The court recorded Sun's description of it: JNI links Java code to native code through the Java virtual machine, and provides native code with access to the Java Virtual Machine, and it allows an application that mixes the two to run on any Java-compatible virtual machine.

Microsoft's virtual machines did not support it. They supported three interfaces of Microsoft's own instead — the Raw Native Interface, Java/COM and J/Direct — and Sun's contention, as the court summarised it, was that software using any of the three will not run on Java runtime interpreters supporting only Sun's JNI, and that this fragments the Java environment on Windows. The technical dispute that followed was almost entirely a question of contractual definition rather than of engineering: whether JNI counted as part of the applet application programming interface that Microsoft's products had to comply with, and whether an interface that did not exist when the licence was signed could be brought within it by the licence's own upgrade language. The district court answered both questions yes, and the appellate court found that reading grammatically plausible and supported by the record.

Remote method invocation is the other omission usually named, and honesty requires reporting how thin the record on it actually is. Sun contended that Microsoft's development kits and Visual J++ 6.0 failed its RMI compiler tests. Microsoft answered that the RMI compiler was a Supplemental Java Class under the agreement, that the agreement obliged it only to post such classes on its website rather than to include them, and — as the district court recorded — Sun's reply brief offered no opposing argument. RMI is therefore properly listed among the things Microsoft's Java did not have, and not among the things the injunction turned on.

Taken together the two halves describe a single strategy with a single effect. The extensions gave a developer reasons to write code that only Microsoft's runtime could execute; the omissions removed the standard route by which such code might have been written portably. Neither on its own would have been fatal to the compatibility regime. Both at once meant that the shortest path from a Windows desktop to a working program ran outside the specification in both directions.

Sun's technical objection, in Sun's own words

Sun published its technical case against the delegate construct on its own website, in a paper by the Java Language Team titled About Microsoft's "Delegates", archived in February 1999. It is the clearest surviving statement of the argument as a language-design argument rather than a legal one, and it makes an admission that is more interesting than any of its objections.

The paper's opening is flat: the construct and the two keywords introduced to support it are not a part of the Java programming language, and it is unlikely that the Java programming language will ever include this construct. Then comes the admission. Sun had considered adopting bound method references in 1996, to the extent of building and discarding working prototypes, and had concluded that they were unnecessary and detrimental to the language. The paper names the party Sun consulted before deciding: Borland International, who had previous experience with bound method references in Delphi Object Pascal.

The reasons given were four. Bound method references add complexity, requiring an entirely new kind of type and new rules for matching expressions to it. They lose object orientation, because such references are second-class citizens among reference types — the paper notes that Visual J++'s delegate types, although technically classes, cannot extend classes chosen by the programmer or implement arbitrary interfaces. They are limited in expressiveness, being no more expressive than function pointers, unable to hold state or implement groups of operations. And they are no more convenient than the alternative, because the extra notation required by inner classes is never more than a handful of tokens. Sun's positive claim was that inner classes provide equal or superior functionality and had already been used to build a user-interface library at least as comprehensive as the Windows Foundation Classes.

The last objection is the one that reaches beyond taste. Multiple kinds of method linkage, the paper argued, dilute the investment in VM technologies, because every virtual machine must then handle additional and disparate reference types efficiently. That is a compatibility argument dressed as an engineering one, and it is the real content of the disagreement: a specification is a promise about what implementers will have to build, and every construct added by one implementer is a bill sent to all the others.

The circularity of the whole episode is best left as an observation rather than a verdict. Bound method references reached Java's neighbourhood from Delphi; Sun consulted Delphi's makers and rejected them; Microsoft added them to Java, having in the interim hired Delphi's chief architect; and the construct's final home was a new language written by the same architect, where it is spelled with the same word.

The action of October 1997, and the first injunction

Sun filed suit on 7 October 1997 in the United States District Court for the Northern District of California, case number C 97-20884 RMW, before Judge Ronald M. Whyte. The claims as originally pleaded included trademark infringement, unfair competition and breach of contract. The record describes the trigger in Sun's own terms: in late 1997 Sun had become concerned that Microsoft was distributing a polluted version of Java, modified in ways that made it incompatible with Sun's standards.

The first relief sought was narrow and was about a logo. In November 1997 Sun moved for a preliminary injunction barring Microsoft from using Sun's Java Compatible mark on products that failed Sun's compatibility tests. On 24 March 1998 the district court entered that injunction. Microsoft did not appeal it, and by its own later account had stopped using the mark from that year onwards. It is a small step in the record but a clarifying one: the very first thing a court ordered in this dispute was not that Microsoft change its software, but that it stop describing the software as compatible.

Sun then amended its complaint to add a copyright infringement claim, and on 12 May 1998 filed two motions for preliminary injunctions: one under section 502 of the Copyright Act, one under section 17200 of California's Business and Professions Code. The copyright motion asked the court to stop distribution of Microsoft's Java development kit outright, and to stop distribution of Internet Explorer and Windows 98 unless Microsoft could show within ninety days that they passed Sun's compatibility tests. The unfair competition motion aimed at licensing practice rather than code: it sought to stop Microsoft conditioning licences for its own products on the use of its version of Java.

The injunction of 17 November 1998

On 17 November 1998 Judge Whyte granted both motions, finding that Sun was likely to prevail on its claims that Microsoft had failed to comply with several of the licence's compatibility provisions and had engaged in unfair business practices. The order that followed is reported at 21 F. Supp. 2d 1109, and it is the most consequential document in the technical history of this product. Its operative provisions, as the record states them, forbade Microsoft from doing the following without meeting stated conditions.

• Distributing, ninety days after the order, any operating system or browser product containing the licensed Java technology unless it included a runtime supporting Sun's JNI in a manner that passed the accompanying compatibility test suite.
• Distributing, on the same ninety-day terms, any Java development tool — the order names the two software development kits and Visual J++ 6.0 — unless it supported JNI, and unless its compiler's default mode had the keyword extensions and compiler directives disabled, with the mode switch arranged to enable rather than to disable them.
• Shipping such a tool without a warning, displayed when a user chose the extended mode either from a command line or from a checkbox, stating that the language extensions produce compiled code which may not run on all compatible virtual machines, and that future versions of the tools might be prohibited by court order from including keyword extensions and compiler directives not contained in Sun's language specification.
• Selling or distributing one named development kit release unless it passed two specific tests, identified in the order only by their numbers.
• Conditioning the right to use the Designed for Windows 95(98)/NT logo, or any licence to any Microsoft product, on exclusive distribution or use of Microsoft's virtual machine; or entering agreements requiring a third party to use Microsoft's native-code interfaces exclusively.
• Advertising any product implementing the technology as the official Java reference implementation.
• Incorporating any additional Microsoft keyword extensions or compiler directives into its Java development tools.

Three details of the order are worth keeping. Microsoft was not required to recall anything, and purchasers were not prevented from continuing to use what they had; the remedy was prospective. Microsoft was required, within fifteen days, to notify its customers — the notice to state expressly that the court had preliminarily found a violation of the licensing agreement, and to name the five items that might ultimately be prohibited: multicast, delegate, @dll, @com and the security directive. That notice was to be posted prominently on Microsoft's website and included in the next quarterly release of the Microsoft Developer Network. And, as a condition of the injunction, Sun was required to post security of $15 million within ten days against the possibility that Microsoft had been wrongfully enjoined.

The middle requirement is the one a directory page about a newsgroup should dwell on, because it is the point at which the case reached the desks of ordinary developers. A court had ordered a compiler to default to standards compliance and to warn its user, in a dialog box, that the convenient mode was a trap. Whatever else the case was about, that is a remarkably concrete piece of software specification to find in an injunction.

The appeal, and what the Ninth Circuit actually held

Microsoft appealed, and the Ninth Circuit — case number 99-15046, argued in San Francisco on 16 June 1999 and decided on 23 August 1999 before Judges Schroeder, Boochever and Hall, with Judge Schroeder writing — vacated the injunction. The holding is routinely misreported in both directions, so it is worth stating exactly as the court did.

On the merits of the contract, the court sided with Sun. There was, it held, significant evidence supporting the district court's conclusion that Sun was likely to prevail on its reading of the agreement and to prove that Microsoft's conduct had violated it. Considerable evidence supported the finding that the extended compiler mode was impermissible; considerable evidence supported the finding that the licence obliged Microsoft to support JNI. None of that was disturbed.

What the court disturbed was the route by which the injunction had been granted. The district court had treated the case as a copyright infringement action, which carried a presumption of irreparable harm once likely success was shown. Microsoft's argument on appeal was that the compatibility requirements were affirmative covenants rather than limitations on the scope of the licence, so that a breach sounded in contract and not in copyright — and the district court had never expressly ruled on that question. The appellate court agreed that it should have: it should not have invoked the presumption of irreparable harm applicable to copyright infringement claims before it determined that the compatibility requirements were a limit on the scope of the license rather than independent contractual covenants. The injunction was therefore vacated and the case remanded. The court did not answer the covenant question itself.

The unfair competition portion fell for a separate and narrower reason. The district court had rested it solely on past conduct, and under California law an injunction must be based on the prospect of future conduct. That part too was vacated and remanded for reconsideration. The net effect, in August 1999, was that Microsoft was under no injunction and had lost none of the substantive arguments.

On remand, and the settlement of January 2001

Sun moved to have the November 1998 injunction reinstated on the unfair competition ground, and on 24 January 2000 Judge Whyte granted that motion in part. The standard applied was the alternative branch of the preliminary injunction test: Sun had at least raised serious questions going to the merits, and the balance of hardships tipped sharply in its favour. The reinstated order carried most of the technical requirements forward — JNI support in operating systems and browsers, JNI support in development tools, the compiler default with extensions disabled and the mode switch arranged to enable them, the warning dialog, and the ban on advertising the implementation as official — and added a new prohibition aimed squarely at description rather than code: Microsoft was not to advertise, promote or publicly describe the @com, @dll and @security directives as complying with Sun's specifications or as approved by Sun. It also required that the development tools include at least as much support for JNI as for Microsoft's own Raw Native Interface, help files and header files included.

The case ended a year later. On 23 January 2001 the two companies settled, and Microsoft's own announcement is the cleanest statement of the terms. It settled both the October 1997 suit and Microsoft's counter-suit. The 1996 licence agreement — which, the announcement noted drily, was due to expire in two months — was terminated. Microsoft could continue to ship all current products and those in beta containing Sun's technology for a period of seven years. Microsoft agreed not to use Sun's Java Compatible trademark, which it has not done since 1998. And Microsoft paid Sun $20 million.

A court in a later case summarised the same agreement in six points, and the summary adds three things the press release does not emphasise: that Microsoft's distribution of its virtual machine was required to be phased out over time, that the virtual machine could be based only on the older Java technology, and that Sun released all of its claims arising out of the California litigation except its antitrust claims. The freeze at the older feature set is what made the settlement fatal to the product rather than merely expensive; reference accounts put that freeze at the feature set of Java 1.1.4. An implementation permanently pinned to a 1997 language level had no future as a Java implementation, whatever the licence permitted. And the reservation of the antitrust claims is what made the settlement not the end of the story.

The second case: Maryland, and the must-carry injunction

Shortly after Microsoft began commercial distribution of Visual Studio .NET in February 2002 — the release that introduced both C# and the replacement for Visual J++ — Sun commenced a fresh action in the Northern District of California. The complaint ran to sixteen counts and combined antitrust claims under section 2 of the Sherman Act with a copyright claim under section 501. The suit was transferred to the District of Maryland for inclusion in the ongoing multidistrict Microsoft antitrust litigation.

After a three-day hearing the district court issued an opinion in December 2002 and its order on 21 January 2003. There were two injunctions. The first, under section 16 of the Clayton Act, was mandatory and, as the district court itself acknowledged, unprecedented: it required Microsoft to incorporate and distribute Sun's Java software with every copy of its Windows operating system and its browser — a must-carry obligation, justified by the court on the theory that Microsoft was leveraging a monopoly in PC operating systems into an emerging market for general-purpose, internet-enabled distributed computing platforms. The second, under section 502 of the Copyright Act, was prohibitory: Microsoft was barred from distributing any product containing its own virtual machine other than a product licensed under the 2001 settlement.

Microsoft's own Java page recorded what happened next, in a notice that was still on its website that summer: on 3 February 2003 the Fourth Circuit granted a stay pending appeal, and the notice adds that the decision came as the company was taking the first of many steps to comply.

The Fourth Circuit decided the appeal on 26 June 2003, Judge Niemeyer writing for a panel that included Judges Widener and Gregory. It split the two injunctions. The must-carry injunction was vacated: the district court had been unable to find immediate irreparable harm — it could not say that tipping in Microsoft's favour would more likely than not occur, nor find an imminent threat of it — and the relief did not aid or protect the court's ability to grant final relief on the operating-systems monopolisation claim it had actually been asked to decide. The copyright injunction was affirmed: the district court had not erred in construing the scope of the licence Sun had granted, nor abused its discretion in entering the order.

All of it ended on 2 April 2004, in San Francisco, with an agreement that settled every piece of litigation between the two companies at once. The announced terms were payments of $700 million to resolve pending antitrust issues and $900 million to resolve patent issues, with Microsoft making a further up-front payment of $350 million in royalties under a ten-year technology collaboration arrangement. That is the date on which the argument that began with a compiler flag in 1997 was finally paid for.

This is not the browser case

Two large Microsoft cases of the same years are routinely run together, and this page's subject is the smaller and less famous of them. They should be kept apart, and the distinction is easy to hold.

Sun Microsystems, Inc. v. Microsoft Corp. was a private commercial action between two companies, begun in California in October 1997, founded on a licence agreement and on copyright, and later joined by private antitrust claims that were transferred to Maryland. Its central document was a contract; its central question was whether a licensee had exceeded the scope of its licence; and it ended in negotiated settlements in 2001 and 2004 without any final judgment on the merits.

United States v. Microsoft Corp. was a government enforcement action begun in Washington, D.C., in May 1998, tried before Judge Thomas Penfield Jackson, decided on appeal by the D.C. Circuit in June 2001, and concerned with monopoly maintenance and the bundling of a browser. Microsoft's Java conduct appears in that case too — the virtual machine was cited there as an instance of the strategy the trial record described — but as evidence in a monopolisation case, not as the subject of one. The browser war, its complaints and its court record belong to alt.netscape.sucks and are not retold here. A reader who encounters a claim that the courts ruled against Microsoft over Java should ask which court, which claim and which year, because the honest answers are not the same for the two cases.

What replaced it

The product's own end is undramatic in the record. Visual Studio 6.0 remained the last suite to contain Visual J++; reference accounts date the discontinuation of the product to January 2004. The virtual machine was wound down under the terms of the settlements, which permitted Microsoft to keep issuing security fixes; support for it ended on 31 December 2007. In between, Microsoft published a Java Language Conversion Assistant, a tool whose entire purpose was to convert existing Java source into C#, and which sat on the company's Java page in 2003 as a public beta. A migration tool of that kind is a fairly exact statement of corporate intent.

The nominal successor was Visual J#, launched on 1 July 2002 and built not in Redmond but by Microsoft's development centre in Hyderabad. It used Java's syntax and was offered as a transition path for developers with existing Java or Visual J++ code, but it was a different proposition in one decisive respect: it targeted the .NET Framework and only the .NET Framework, producing no Java bytecode and running on no Java virtual machine. It supported neither JNI nor Microsoft's own Raw Native Interface, substituting the platform invocation services of the new runtime, and it did not support remote method invocation or applet development at all. In January 2007 Microsoft announced its retirement from future versions of Visual Studio; a second edition of the 2.0 redistributable followed in May 2007 to satisfy demand for 64-bit support; the version shipped with Visual Studio 2005 was the last, supported into the middle of the following decade.

The real successor was a new language. C# began in January 1999, when a team was formed inside Microsoft to build a language then called COOL; by the Professional Developers Conference of July 2000, at which the .NET platform was announced, it had been renamed, and it was first widely distributed that month. It was approved as an Ecma standard in 2002 and as an ISO/IEC standard in 2003 — which is to say that the company that had been enjoined over extensions to somebody else's specification put its own language through a standards body at the first opportunity.

The name usually attached to it is Anders Hejlsberg, and the chain of employment is the reason this section belongs on this page rather than on a general history of programming languages. Hejlsberg wrote Turbo Pascal, became chief architect of Delphi at Borland, left Borland in October 1996 for Microsoft, and worked there first on Visual J++ and the Windows Foundation Classes; from 2000 he was lead architect of C#. The construct Sun rejected in 1996 after consulting Borland, and which Microsoft added to Java in 1997, is a first-class feature of C# — declared with the keyword delegate, and supported in the runtime library by base classes named Delegate and MulticastDelegate, the same two names the 1998 injunction had spelled out. That lineage is neither hidden nor disputed; it is simply where the extensions went after the courts told them to leave.

Two boundaries should be marked. The .NET runtime's own later career as a platform — managed code sitting over a natively designed interface, and what that felt like to the developers using it — belongs to the Managed DirectX group's page and is not duplicated here. And most of the dates in this section fall outside the window the gateway that produced this directory actually covered. news2mail carried Usenet to e-mail between 2000 and 2004. The J# retirement announcement of January 2007, the end of virtual machine support in December 2007, the support horizons of 2015 and 2017, and Microsoft's eventual resumption of distributing a Java runtime — a build of OpenJDK, from 2021 — all postdate the gateway entirely, and postdate the removal of this newsgroup by years.

The French room, and the French room that was not Microsoft's

French-speaking developers did not wait for Microsoft to give them somewhere to discuss Java, and the paperwork proving it is better than anything this group left behind. On 22 May 1996 a control message went out from [email protected] creating fr.comp.lang.java. It announces, in French and then in English, that the unmoderated group a passe avec succes l'epreuve du vote (198:2) — passed its vote, 198 to 2 — and it carries a charter. The charter opens the group to any discussion touching Java, and then itemises: development problems and the solutions proposed for them; tools around the language, naming compilers and development environments, the JDK, HTTP servers and Java-capable browsers; security problems lies a Java et aux differentes versions des JVM; and product announcements, provided posters respected the non-commercial character of messages posted outside the fr.biz.* hierarchy.

Three things in that document are worth noticing. It is dated three months before Internet Explorer 3 put a Microsoft virtual machine on Windows desktops, and more than four years before Microsoft gave France a Visual J++ room. It was created by a public vote with a published tally, in a community-governed hierarchy, and it is still in the master newsgroups file today, described in French as Le langage de developpement Java. And its charter, written in the spring of 1996, already speaks of the different versions of the virtual machine in the plural, as a topic on which readers would have security questions. The fragmentation that the courts spent six years arguing about was, to the people who had to write code against it, simply a fact of the landscape from the beginning.

Set against that, microsoft.public.fr.jpp is a room of a different kind: created by fiat in a three-second burst of twenty-one names, given no charter, given a description generated from its family rather than written for it, and removed by fiat with a message that contained no text. Neither model is presented here as the better one. They are simply the two ways a francophone developer could be given a place to ask a question in 2000, and only one of the two is still in the catalogue.

The language question in this corner had a particular sharpness that the branch-level page does not cover, because it touches the disputed word itself. On 16 March 1999 the Journal officiel de la Republique francaise published the official French term for applet: appliquette, feminine noun, filed under computing and the internet, and defined as a small application independante du materiel et du logiciel utilises — independent of the hardware and software in use — downloaded from a server on the web and executed locally inside a browser, with an accompanying note that appliquettes are chiefly written in Java. The French state's official definition of the thing thus asserted hardware and software independence as a defining property, in the same months that a court in California was working through the evidence on whether the most widely installed implementation of it on Windows had that property at all. The terminology was not wrong; it was describing the specification. It simply had no way to describe the gap between the specification and the machine on the desk.

The French branch's later Java room went the same way as this one, a little more slowly. microsoft.public.fr.dotnet.vjsharp — the francophone room for the J# successor — has exactly one archived control message, a PGP-signed removal dated 15 December 2009. It came not from Microsoft but from a francophone volunteer whose key the hierarchy's published control configuration recognises for microsoft.*, the arrangement that file describes as control articles issued not by Microsoft itself but by a Usenet participant, to improve the propagation of the company's newsgroups. Five French .NET rooms survive in the master file today; none of them is for J#. French-language Usenet more generally, the fr.* and alt.fr.* hierarchies, the keyboard and the terminology arguments are covered on alt.fr.comp.os.ms-windows.xp, and the shape and administration of the French Microsoft branch on its own page.

What the record does not show

Everything above is context, administrative record or court record. None of it is testimony about this newsgroup, and the gap should be stated in full rather than glossed.

No archive of this group's traffic has been read for this page. No posting is described, quoted or summarised. No participant is named. No subscriber count, article count, thread or volume figure is known or asserted, and none appears anywhere in the material consulted. Whether the room was busy, quiet or entirely empty is not settled by anything on this page. Whether anyone in it ever discussed the litigation — which would have been the obvious thing to discuss, and which is exactly why it should not be assumed — is unknown.

The group also has no charter and never had one. The hierarchy did not write charters; the one-line description that circulated with the name was generated by family, and since the name has been removed from the master file, even that line no longer exists to be quoted. The removal message of January 2005 states no reason, and Microsoft's control messages in this hierarchy never did.

Two inferences are tempting and both should be resisted. The first is that the removal proves the group was dead. It proves that somebody at Microsoft was clearing obsolete product names, which is why it went out in company with rooms for SNA Server, Internet Explorer 4, a shipped beta and BackOffice; a busy group whose product had been discontinued would have been removed on exactly the same list. The second is that the group's existence proves French developers were using Visual J++ in 2000. The creation burst of 28 August 2000 transcribed a product catalogue into a namespace; a room was created because a product existed, not because questions were arriving.

One further caution applies to the litigation sections. Every holding above is reported as the court stated it, at the stage of proceedings at which it was stated. Preliminary injunctions rest on findings of likely success, not on final determinations; the Ninth Circuit vacated one such injunction without deciding the question it identified; and the case ended in settlement, which means that on the merits nothing was ever finally adjudicated between these parties. Nothing on this page adjudicates it either.

Scope and limits

The sources for this page are short enough to list. For the group itself: the Internet Systems Consortium's archived control file for microsoft.public.fr.jpp, containing three articles, read directly, with their dates, senders and message identifiers taken from the messages themselves; the consortium's current master newsgroups and active files, checked for the name's presence and found not to contain it; and the archived control files for the other 162 names beginning microsoft.public.fr., read and counted for the days on which this group was created, reissued and removed.

For the product: standard reference accounts of Visual J++, the Microsoft virtual machine and Visual J#, and the published release history of the Visual Studio suites in which the product shipped. For the technology: Sun's own contemporaneous white paper on the delegate construct, as archived in February 1999, and the definitions of the licence terms as the courts reproduced them.

For the litigation: the district court's order of 17 November 1998 and its order of 24 January 2000 on remand, both read in full; the Ninth Circuit's opinion of 23 August 1999 in case 99-15046, read in full; the Fourth Circuit's opinion of 26 June 2003, read in full; and Microsoft's own press releases of 23 January 2001 and 2 April 2004, read from archived copies of the company's site. Quotations from any of these are exact or absent. For the French terminology: the entry for appliquette in the French state's terminology database, which gives its Journal officiel date and its official definition.

Several adjacent subjects belong to other pages of this directory and are deliberately left there. The construction, governance and 2010 closure of the microsoft.public.* namespace, and the recognition programme that identified its most active answerers, are on the microsoft.public.* hierarchy page linked above. The French branch as a whole, its 103 surviving names, its administrative record and the francophone developer's working conditions are on the French scripting group's page linked above. The browser war and the government antitrust case are on alt.netscape.sucks, linked above, and are a different case from this one.

A last caution about every number here that comes from the consortium's files. Those files describe a namespace, not a network. A name in them means administrators were offered the name; its absence means somebody asked for it to be withdrawn and enough of them agreed. Neither fact measures how much was ever posted, and nothing on this page treats them as though it did.