把既有程序员带到新平台

J♯的设计问题来自微软推广.NET时面对的既有代码与人才。企业中已经有使用Java语法和Visual J++编写的程序，迁移平台若意味着全部重写，就会同时损失软件积累和人员经验。微软希望保留这些投入，让程序员利用.NET的网络服务、数据库访问和窗口界面能力。

相关工作分布在微软的开发组织中。2001年2月，位于印度海得拉巴的微软印度开发中心公布，自己正在开发JUMP to .NET，即Java用户迁往.NET的工具与技术。这个项目体现了当时的迁移方向；同年公布的J#则把Java语言开发与Visual Studio、.NET运行环境组合为具体产品。

参考：[1] [2]

测试版和正式发布的两个时间点

2001年10月10日，微软宣布Visual J# .NET Beta One可以取得，面向希望在.NET上构建应用与服务的Java语言开发者。公告特别列出Visual Studio集成、跨语言协作，以及Visual J++ 6.0工程升级工具，说明测试对象不仅是语法，还包括从旧工程到新开发流程的过渡。

正式发布发生于2002年7月1日的巴塞罗那TechEd 2002 Europe会议。现有Visual Studio .NET用户可通过微软及MSDN渠道取得产品。微软在发布时声明它是自行开发的工具，并未获得Sun Microsystems认可；发布地点、测试时间和开发组织各自对应不同阶段。

参考：[2] [3]

语法保留，执行目标改变

J#使用Java式语法，但程序进入的是.NET公共语言运行库，即CLR。它把源代码编译为微软中间语言MSIL，而不是供Java虚拟机执行的字节码。2003年的技术说明还介绍二进制转换工具，可把一部分既有Java字节码静态转成MSIL；有源代码时，通常更适合重新编译。

微软另行提供类库，以实现大部分JDK 1.1.4层级功能及若干扩展，并使程序能够调用.NET类库。既有包名和类的接口因此可以在新的运行环境中复用；迁移工作还要检查程序实际使用的库和平台机制。

参考：[4] [5]

从一个输出程序看两层接口

微软存档手册中的简单例子先用import System.*引入.NET命名空间，再定义Hello类，并以public static void main(String[] args)作为入口；方法体调用Console.WriteLine输出一行文字。类、入口方法和参数写法保持Java程序员熟悉的结构，真正执行输出的Console却来自.NET。

这个例子体现了J#的使用方法：程序员不必先把整个程序改写成另一种语言，就能接触目标平台的功能。2016年存档的Visual Studio 2005文档仍保留这一结构，并明确列出vjc.exe编译器和JbImp.exe二进制转换工具。后者处理已有二进制的用途，与前者处理源代码的用途分开。

参考：[5]

工程升级有明确边界

官方发布材料把Windows Forms、ASP.NET、ADO.NET和XML网络服务列为使用场所。Visual J++ 6.0升级工具能转换工程和解决方案格式，帮助旧项目进入新的开发环境。应用迁移随后还要检查代码、依赖库与运行行为。

早期技术说明指出，J#面向CLR生成应用，支持范围不包含Java原生接口JNI、远程方法调用RMI等机制。依赖这些功能的程序需要重新安排接口。2003年版进一步纳入Visual Studio .NET产品体系，使Java式语法、兼容类库与.NET功能共同进入其开发流程。

参考：[3] [4]

类库复用与后续部署

硬件接口软件提供了实际复用的例子。Maxim的1-Wire驱动安装说明记载，其.NET支持是把原有1-Wire Java应用程序接口用Visual J#编译，形成OneWireAPI.NET.dll。上层应用可以使用这个库，部署时须同时安装.NET、J#再分发包、相应硬件驱动和TMEX接口文件。

这份修订说明使用的是.NET 2.0和J# 2.0 Second Edition，属于后续版本的应用。微软的后期文档也单独说明64位运行支持。最初的代码迁移方向由此延续到后来版本，运行库与底层依赖的配合始终是部署工作的一部分。

参考：[6] [5]