微软当年的 J++ 究竟是什么？为什么 Sun 要告它？
Java 语言最初是由 Sun Microsystems（后来被 Oracle 收购）在 90 年代中期推出的，以其“一次编写，到处运行”的跨平台特性迅速获得了巨大的成功。Sun Microsystems 围绕 Java 构建了一个庞大的生态系统，包括 Java Development Kit (JDK) 也就是开发 Java 程序所需的工具包，以及 Java Runtime Environment (JRE) 也就是运行 Java 程序所需的虚拟机和类库。
微软当然看到了 Java 的巨大潜力，他们也想在蓬勃发展的互联网时代分一杯羹。于是，微软决定在自己的 Windows 平台上实现 Java。但微软并没有完全按照 Sun Microsystems 的规范来做，而是加入了许多他们自己特有的功能和扩展，并给它起了个名字叫做 "Microsoft Visual J++"。
你可以把 J++ 理解成一个“特供版”的 Java。它在语法上基本上兼容 Java，你用 J++ 写的很多代码也能在标准的 Java 环境下运行。但微软在 J++ 里加入了很多 Windows 特有的技术，比如 COM (Component Object Model) 组件对象模型。这就像是微软在 Java 这门语言的“车身”上，又塞进了很多自家特有的“发动机”和“电子设备”，让它能更好地与 Windows 系统深度整合，并且提供一些标准 Java 没有的、或者在 Windows 上实现起来更方便的功能。
那么，为什么 Sun Microsystems 要告微软呢？这背后主要是因为版权、许可协议和商业利益的冲突。
Sun Microsystems 在推出 Java 时，确实采取了一种比较开放的策略，允许第三方实现 Java 虚拟机和开发工具，但同时也设定了一些规则和要求。其中最重要的一点是，任何实现 Java 的厂商，都需要遵循 Sun 对 Java 的技术规范，并且需要通过 Sun 的兼容性测试。通过这个兼容性测试，Sun 才能确保各个版本的 Java 能够真正做到“一次编写，到处运行”，维护 Java 的跨平台承诺。
微软的 J++，虽然表面上看起来是 Java，但它在技术实现上，以及最重要的——它对 Java 规范的遵循程度上，与 Sun 的要求存在很大的出入。微软为了让 J++ 与 Windows 平台更紧密地结合，加入了很多只有在 Windows 上才能实现的特性，并且这些特性并没有得到 Sun 的认可。更关键的是，微软没有按照 Sun 的规定，通过 Sun 的官方兼容性测试。
Sun Microsystems 认为，微软这种做法，破坏了 Java 的核心理念——跨平台性。用户如果习惯了使用 J++ 开发，然后期望他们的 Java 程序能够在其他操作系统上也能运行，很可能会因为 J++ 的那些“特供”功能而遇到问题。这不仅损害了 Java 的声誉，也威胁到了 Sun 在 Java 生态系统中的控制力和商业模式。
而且，微软当时正在大力推广自己的 Windows 平台和 ActiveX 等技术，他们希望通过 J++ 来吸引开发者，让他们在 Windows 平台上构建应用程序，而不是在其他平台上。从 Sun 的角度来看，微软的 J++ 就像是微软在 Java 这个“公共语言”的基底上，强行打上了“Windows Only”的烙印，这与 Java 的开放和跨平台精神背道而驰。
简单来说，Sun Microsystems 觉得微软是在“偷梁换柱”，借着 Java 的名义，实际上是在推广自己的封闭生态系统，并且没有遵守当初的合作约定。所以，Sun 认为微软的行为构成了对 Java 品牌和技术的侵犯，从而采取了法律手段来维护自己的权益。
这场官司最终以微软同意停止销售和支持 J++，并更改其 Java 开发工具的名称（后来变成了 Visual J，而 J 更加倾向于 .NET 平台，与 Java 已经有了较大的区别）而告一段落。这件事也对 Java 的发展和微软在 Java 领域的策略产生了深远的影响。
网友意见
目前排名第一的
猫杀的答案不错。我想就所谓“Microsoft J++”到底是什么稍微补充几点。
本文提到的“Sun JVM”主要说的是Sun JDK 1.0.2带的那个元祖JVM。它在后来的Sun JDK里被称为Classic VM，再后来被HotSpot VM所替代。
当时（Sun JDK 1.0.2）的Java跟现在的Java不可同日而语。别提标准不标准，当时的Java毛都没有，很多东西所谓“标准”就是“Sun怎么实现”。
为什么Sun要告微软？微软“不乖”，“擅自”扩展Java让它在Windows上变得更好自然是一方面；另一方面Sun对它的Java合作伙伴们普遍态度恶劣，非常傲慢和小心眼，这才是更重要的方面。
这方面请参考另一个问题的回答：
如果当时 Sun 没有起诉微软，而微软继续保持对 Java 的热情的话，Java 的现状会是怎样？ - RednaxelaFX 的回答另外，想从别的侧面看看当年Sun的行为，看看1997年Sun在benchmark上作弊的事情：
Sun accused over JIT compiler results。这还不是Sun第一次做这种事嗯。
关于控告的过程，请参考当时的新闻稿：
Washingtonpost.com: WashTech -- U.S. v. Microsoft Special ReportMicrosoft J++
Microsoft J++是外界对微软所实现的Java的开发套件和运行时环境的统称。微软自己其实并没有一个叫做“Microsoft J++”的产品（或语言）。微软一直觉得自己实现的就是Java语言，只是稍微根据Windows环境的需要“增强”了一点而已。
微软在JDK 1.0.x时期就获得了Java的授权，将Java移植到Windows平台上。当时的Java真是烂得掉渣，JVM的速度又慢，Java核心库的功能又是要啥啥没有：
例如说能用的容器数据结构就只有Vector、Stack（包装了Vector）、Hashtable（不允许null值）、BitSet，连LinkedList都还没有——“谁会要用链表呢”。
java.math、java.text、java.sql、java.rmi之类的重要的类库都还不存在，locale支持还不存在，图形库只有又慢又不好用的AWT⋯
嗯对，JDK 1.0.2的时候连反射都还没API，java.lang.reflect也还不存在。Java语言里“接口”这个语言结构也还不存在。
JNI（Java Native Interface）标准也还不存在。Sun JDK 1.0.2只有一个非常原始的native interface，而它允许native代码直接访问Java对象的内部结构，既不安全也不可移植。更新信息可以参考当时的文档：
Integrating Native Methods into Java Programs。
而这个时候Windows上已经有很多可用的库，更重要的是：
- 它们有很多都以COM的方式暴露接口
- Java的对象技术其实跟COM有许多重叠之处
于是让Java能够更好的利用Windows上已有的资源，真正在Windows上成为一等公民，微软给Java添加了：
- J/Direct与RNI（Raw Native Interface）：用于与native代码交互
- Java/COM：让Java能够使用COM的库，也让Java程序能够暴露出COM接口，便于与其它程序交互。参考这里：Can You Implement COM Components Using Java?
- 委托（delegate）：现在Java 8也有lambda，大家都知道这个是什么了。当时要引入委托主要是为了更好的支持事件模型的回调。详情可以参考微软对Java委托的专利：Patent WO1999063433A1，以及MSDN的文档 Delegates in Visual J++ 6.0。微软当时为Java实现了委托之后把全套代码交给了Sun，向Sun申请添加该功能到标准Java。结果Sun暴跳如雷急忙批判微软要分裂Java…
- 还有一大堆的库。例如Windows Foundation Classes (WFC)。WFC包装了Win32和DHTML的图形组件库。Win32的部分跟后来.NET的Windows Forms（WinForms）很像。
- 等等⋯
微软版的RNI在Sun版的JNI之前就已发布，自然就不大愿意再实现一个功能非常相似的东西。但微软决定不在MSJVM里实现完整的JNI成为了后来打官司的关键因素之一。
当年微软给Java加了的功能，现在Oracle在一点点给Java加上⋯
- Java SE 8给Java语言加上了lambda与method reference；
- Java SE 9正在计划给Java加上跟J/Direct类似的新的、更方便的native interface
Microsoft Visual J++
Visual J++，这是一个实际存在的产品的名字。它是一个用于开发Java应用程序的IDE，里面还包含有IE3.0之类的“附属物”。Visual J++有单独发布的版本，后来被整合到Visual Studio里发布。
Microsoft SDK for Java (MSJDK)
这是Sun JDK的微软版对应物，独立于Visual J++免费发布。它包含开发Java应用程序所需要的工具套件，例如Java源码编译器 jvc（与Sun JDK的javac对应），Java的命令行启动程序 jview （与Sun JRE的java命令对应） ，Java Applet Viewer，Java核心库，还有Java虚拟机（MSJVM），等。
有个有趣的工具叫做 jexegen。顾名思义，它用于为Java程序创建一个可执行程序，把Java程序所需的Class文件打包在生成的exe里。这跟后来.NET Assembly的做法很接近：它是一个PE文件，不过启动之后马上会去加载MSJVM来执行打包的Class文件。能生成出可执行文件让Java写出来的程序能更符合Windows的用户习惯。
Microsoft Compiler for Java (jvc)
jvc 是微软自己实现的Java源码编译器，应该是用C++实现的（求证）。
它的编译速度非常快，而且编译时会做许多优化，编译出来的代码质量也比较高。
相比之下，同时期Sun的javac是用Java实现的，编译速度慢一些；虽然也做一定量的优化，但没 jvc 做得深。
jvc 跟当时IBM的
Jikes编译器（跟后来的Jikes RVM不是同一个东西）地位相似。两者都用native语言实现（Jikes用C++），编译速度都比较快，而且都做比较多优化。
同年代同样用native语言实现的Java源码编译器还有Symantec Café Compiler。
jvc 支持所有标准的Java语言特性，外加支持如delegate、J/Direct之类的微软扩展的特性。
话说有个黑历史非常搞笑：Sun在控告微软的jvc不兼容Java规范的时候，指责jvc生成的Class文件通不过TCK1.1；然后微软不但说明Sun没用对命令（故意打开了微软扩展来测试），而且进一步说明Sun的javac其实也不能完全通过TCK1.1；关掉了扩展的jvc能通过的TCK1.1测试比Sun的javac能通过更多。
Microsoft Virtual Machine for Java (MSJVM, Microsoft VM, MSVM)
这是微软实现的JVM。最初的代码来自Sun授权的Sun元祖JVM，后来被魔改成Windows上最快的JVM实现。
IE3 Beta 1的时候带的MSJVM还只有解释器，到IE3 Beta 2就开始带有JIT编译器了。
MSJVM魔改了Sun JVM核心的每一方面。
- 对象模型：Sun JVM的对象模型把“对象头”放在了handle里，使“对象头”跟对象实例数据分离到不同的地方了。MSJVM去掉了handle这层间接，于是把对象头与对象实例数据重新“粘”到了一块。关于MSJVM的对象模型，我在另一个回答里简单提了一下：为什么bs虚函数表的地址（int*）(&bs)与虚函数地址（int*）*(int*)(&bs) 不是同一个？ - RednaxelaFX 的回答
- 基于直接指针而不是基于handle的引用，访问效率更高。
- GC：准确式的、分两代的copying GC。文档里还专门说了没使用mark-compact算法。当时的Sun JVM使用的是半保守式、不分代的mark-sweep（带可选compaction） GC。
- 对象同步：使用synchronization block而不是老Sun JVM的monitor cache。在对像头里包含有一个指向synchronization block的指针；该指针位于对象的负偏移量上。后来的CLR的对象头采用了同样的布局。在对象头里持有这样的指针大幅减少了查找对象的monitor的事件。Sun JVM是维护一个全局的用hash table实现的“monitor cache”，把对象的handle强制转换成int当作key去查找这个cache里的monitor，每次查找都是一个hash lookup。
- 线程：使用native线程，管理线程用的数据结构稍微调整过。Sun JVM在Windows上的版本用native thread，而在Solaris上的版本则是使用green thread（JVM自己调度的用户级线程）。
- 添加了JIT编译器：Sun JVM在JDK 1.0.x的时候只有个很简陋的JIT编译器接口，但没有发布JIT编译器的实现。MSJVM改造了这个接口并且提供了一个当时性能还不错的JIT编译器实现，而且配合准确式GC提供必要的信息。
- RNI：在Sun JVM的native interface的基础上衍生出的一套native interface。
- Java/COM在MSJVM内的支持
MSJVM基本没怎么改动的可能也就是解释器的核心循环了。原本在Sun JDK 1.0.2的时候，Sun JVM的解释器循环用纯C实现，写得很直观但性能很渣；到Sun JDK 1.1.0的时候
改为用汇编实现，写得比较高效，所以也就没啥必要魔改这部分，小改动然后直接用就好。顺带一提，Sun JDK 1.1.0的JVM的解释器，在x86上的版本是Intel贡献给Sun，而不是Sun自己写的⋯呃呵呵。
Sun那边的JIT编译器有好多黑历史⋯Sun JDK 1.0.2自己没有带JIT，不过有一个单独销售的产品叫“Java Workshop”，里面带有一个能插入Sun JVM的JIT，这个JIT编译器叫做“sunwjit”。
可以从
这里下载到描述sunwjit的一篇文章（CompileJava97.pdf，“Compiling Java Just in Time”）。
后来Sun JDK 1.1.x的时候开始带JIT发布了，但却只在Solaris版上带有sunwjit，而在Windows版上带的是Symantec的JIT（“symcjit”）。
据说James Gosling原本自己写过一个JIT编译器，但是没发布被抛弃了。不知道这跟sunwjit是啥关系呢。
Microsoft Internet Explorer 3.0 (IE3.0)
IE3.0真是当年的技术急先锋。一方面搭载了JScript来跟Netscape的JavaScript抗衡，另一方面捆绑了MSJVM以便支持Java。
先写这么多吧⋯
=============================================
后话
所以说当时MSJVM至少可以从三个地方获取：IE3、Visual J++/Visual Studio、MSJDK。MSJVM的许可证也允许第三方程序捆绑它发布。
顺带一提，根据
Patrick Dussud在Channel 9上的一个访谈里提到的，微软里其实还有过一小撮人做过一个非正式项目，是写一个全新的、“clean-room”（不衍生自Sun的代码）的JVM原型。这个项目最后没有进入产品。或许如果当年Sun没有禁止微软开发新版本Java的话，微软也会像IBM开发出全新、clean-room的J9 VM一样有自己独立的JVM。
然而历史没有如果。那个clean-room的JVM原型为后来的CLR的研发积累了不少经验。
我觉得现在这样也挺好的。.NET总算没把Java所有的历史包袱都带上，CLI（Common Language Infrastructure）的基础设计又比JVM的更进步和完善。
类似的话题
-
微软当年推出的 J++，简单来说，是微软自己开发的一个版本的 Java 语言。你可以把它想象成微软对 Java 这套语言和运行环境的“再创作”。Java 语言最初是由 Sun Microsystems（后来被 Oracle 收购）在 90 年代中期推出的，以其“一次编写，到处运行”的跨平台特性迅速获............. -
说微软当年用“并不比苹果好”的技术战胜了苹果，这其实是一个颇具争议且需要细致解读的说法。要回答这个问题，我们得把时间线拉回到上世纪八十年代末到九十年代，那个个人电脑市场格局尚未完全定型的关键时期。那个时代的背景：首先，我们得明白，那时候的“技术”和今天的概念有很大不同。苹果在图形用户界面（GUI）方.............
-
如果微软当年没有放弃DOS，而是继续投入研发，今天的DOS恐怕会呈现出一种相当有趣的景象，或许会是这样一幅画面：首先，核心的8位或16位体系结构大概率会被保留，但会有显著的升级。想象一下，我们还在使用着那些熟悉的命令，比如`DIR`、`COPY`、`DEL`，但它们的功能会更加强大和灵活。也许会有更.............
-
说实话，听到安卓最新版微信开放了修改微信号的功能，我挺惊讶的，但也觉得是意料之中的事儿。毕竟，微信这东西，从最初的简单聊天工具，到现在几乎承载了我们生活方方面面，功能迭代肯定会越来越细致，也越来越人性化。关于微信开放修改微信号的考虑，我觉得有几个层面吧：首先，用户体验的优化是肯定绕不开的。回想当初，.............
-
微信“拍一拍”上线，与QQ“抖一抖”的那些事儿说起来，微信这次上线“拍一拍”功能，不少老网民可能心里会泛起一丝熟悉的涟漪——这不就是当年QQ的“抖一抖”嘛！不过，这句感慨归感慨，仔细一琢磨，两者之间还是有不少道道儿可讲的。今天咱们就掰扯掰扯，看看这个新上线的功能，跟当年那个风靡一时的“抖一抖”，到底.............
-
讲到微软的Surface二合一笔记本，很多人可能第一时间想到的是它的“二合一”形态，也就是可以拆卸键盘，既能当笔记本用，也能当平板用。这玩意儿在刚出来的时候，确实挺新鲜的，也吸引了一批尝鲜的用户。但放到现在，市场上的选择多了去了，各种品牌的笔记本、平板，还有一些更垂直的二合一设备，Surface二合.............
-
想象一下，如果当年桑（Sun Microsystems）没有将微软告上法庭，而是选择了一种更加合作甚至可以说是“放任”的态度，那今天的 Java 世界又会是怎样一番景象？这就像一个平行宇宙的猜想，充满了引人遐想的可能性。在那个没有诉讼的宇宙里，微软依然是那个如日中天的科技巨头，而 Java 则是他们.............
-
诺基亚的Lumia系列手机，在微软接手后，曾经是Windows Phone系统的一大亮点。然而，随着微软战略的调整，以及手机业务部门的重组，Lumia品牌的命运也发生了变化。关于微软是否还会为已经出品的Lumia手机推送更新，这需要从几个方面来看。首先，微软的软件支持策略是动态调整的。当一个硬件平台.............
-
张国立转发冯小刚宣传手机2的微博，并配文“做人要厚道”，这件事情确实引发了很多的解读和讨论，其中最普遍的一种声音就是，这似乎是在替崔永元当年鸣不平。要理解这一点，咱们得把时间线往前捋一捋，看看这几位人物之间当年到底发生了什么。首先，要说的是冯小刚的《手机》系列电影。第一部《手机》上映于2003年，是.............
-
疫情防控常态化下，中小微企业和个体工商户面临的困境及解决之道疫情防控常态化，给经济社会发展带来了深刻影响。对于数量庞大、贡献巨大的中小微企业（以下简称“中小企业”）和个体工商户（以下简称“个体户”）而言，他们更是首当其冲，面临着诸多严峻的挑战和困境。以下将详细阐述这些困境，并针对性的提出解决方案。 .............
-
当我们谈论生物进化时，“微观进化”和“宏观进化”这两个词语经常出现。它们各自描述了进化过程中不同尺度上的变化，但核心的驱动机制却是相同的。那么，当这两种尺度上的变化源于同一套过程和机制时，我们是否应该统一使用术语呢？这是一个值得深入探讨的问题。首先，我们需要清晰地理解这两个术语的含义。微观进化 (M.............
-
中国目前确实没有公开展示过类似美国“100吨级”微型可调当量核弹（这里指的可能是美国早期的 Davy Crockett 或 W54 等小型战术核武器，当量通常在百吨至几千吨TNT当量之间）的产品。要深入探讨其中的原因，不能简单地归结为“小型化技术不行”。这背后涉及的是核武器发展战略、技术路径选择、军.............
-
我和我妻子在一起十年了，从我们刚开始谈恋爱到现在结婚，这十年我一直觉得我们是世界上最幸福的两个人。我们有过甜蜜，有过争吵，但总的来说，日子过得平淡却温馨。我从来没想过，这种平静会被一通微信打破。那天，我无意中看到了她手机上一个陌生的名字，那个名字我从来没听过，但她的聊天记录却让我心跳骤停。那些对话，.............
-
微信将全双工手机“降级”为半双工对讲机使用，这到底算不算是一种倒退？这个问题，我觉得得从几个方面掰开了聊，不能一概而论地说好与不好。首先，我们得明白全双工和半双工的区别，以及它们在通信中的意义。 全双工（Fullduplex）： 就像我们打电话一样，你说话的同时，对方也能说话，信息是双向实时交流.............
-
王小山微博“吃翔”事件，想来大家都不陌生。简单来说，就是在2016年美国总统大选投票前，一位名叫王小山的微博用户（也是个挺有名的文化人，写东西的）信誓旦旦地在微博上公开宣称，如果唐纳德·特朗普（Donald Trump）能够赢下美国总统大选，他就要“吃翔”。这可不是什么小事，更像是一场非常极端的政治.............
-
路透社关于刘强东案的报道，确实披露了一些关键细节，尤其是事发当晚，那位女生在微信上的沟通内容。这些细节，特别是她明确表达了“被迫”的意愿，在一定程度上增加了外界对刘强东性侵指控的关注度和讨论。要判断刘强东的性侵指控是否会成立，这是一个非常复杂且需要专业法律判断的问题，绝非我一个AI模型能够给出定论。.............
-
.......
-
.......
-
您好！了解到您的情况，确实挺让人着急的。关于您提到的微信聊天记录截屏能否作为证据，这是一个比较关键的问题。我来给您详细分析一下，尽量把事情说得明白些。首先，要明确的是，微信聊天记录的截屏，在很多情况下，是可以作为证据使用的，但它的证明力强弱，以及是否足够单独构成完整的证据链，需要根据具体情况来判断。.............
-
关于您提到的广州男子在汤加失联并提前转账给妻子的事件，以及当地的救援情况和援助方式，我们来详细解读一下。事件细节的推测与澄清（基于媒体报道的常见情况）：首先，需要明确的是，媒体报道中关于“失联两天”和“海啸来临前转账”的细节，可能是基于家属的担忧、推测或者事后的回忆。在突发灾难情况下，通讯中断、交通.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有