A great many Java developers considered Microsoft's Visual J++ to be the most productive Java IDE (integrated development environment) on the market. The settlement of a lawsuit brought by Sun Microsystems stopped VJ++'s evolution in its tracks and appeared to end Microsoft's involvement with Java.
In a surprising move, Microsoft recently released the latest addition to the .Net constellation of programming languages: J#, pronounced J sharp. Although J# is not Java, it is a full implementation of Sun's Java language specification and will run many existing Java applications after a simple recompile or binary conversion. But J# code neither runs in a Java VM (virtual machine) nor leverages run-time features created after Version 1.1.4 of Sun's Java SDK (software development kit). Microsoft is hoping that the differences between Java and J# will be obvious to lawyers and judges - and that J# will give Java serious competition for the minds of Java developers.
Microsoft has two goals for J#: rescue marooned Visual J++ developers and give other Java coders an easy path to the .Net platform. By promising to match VJ++'s feature set, and most of that promise is realised in this beta, J# gives VJ++ users a soft place to land. Microsoft will have a more difficult time convincing Java developers that they can live without J2EE (Java 2 Enterprise Edition), JDK (Java Development Kit) 1.2 and 1.3 compatibility, and platform independence. The alluring VJ++ environment enticed many programmers to write Java applications that ran only on Windows. Can J# work the same magic for .Net?
The first beta release of J# plugs into Visual Studio.Net Beta 2, rather than the release candidate. The J# beta is incompatible with the VS.Net release candidate unveiled at the Professional Developers Conference, but another J# beta is planned early next year, after the release version of Visual Studio.Net ships. Microsoft will slip a coupon for J# into the VS.Net box, with availability expected in mid-2002. J# is not yet supported by the .Net Compact Framework, but it reportedly will be. The entire J# package, including documentation, fits in a slender 7MB download. The installer integrates J# into Visual Studio.Net, which must already be present. After installation, VS.Net's New Project options are expanded to cover new J# Windows applications, Web applications and Web services. Like other .Net languages, J# compiles to MSIL (Microsoft intermediate language). The J# compiler will not generate Java-compiled byte code (class) files, so it is impossible to run a J# application outside of .Net. You also cannot use compiled Java-class files in J# projects because the .Net run time does not understand Java byte code. If you do not have the source code for the Java classes you use, you would be out of luck if not for Microsoft's byte-code converter.
This clever utility translates Java byte code into MSIL, making compiled Java code run on .Net. Such translation cannot be done at run time; you run the converter during development for each Java class you plan to use, turning the class into a .Net assembly that can be called from J# or any other .Net language. The conversion process is fast, and the converter accepts wild cards and traverses subdirectories to make batch conversion of a collection of Java classes easy.
We found that J# compiled all of the non-J2EE Java code we ran through it without modification, as long as we avoided using features of Version 1.2 and later JDKs. Microsoft supplies assemblies that provide the functionality of Sun's JDK 1.1.4 without using any Sun code, thus avoiding Sun's control and, Microsoft hopes, its legal wrath. J# also implements VJ++ extensions to Java, including COM (Component Object Model) object support and the J/Direct native code interface, making it easy to migrate VJ++ projects to J#. We opened several VJ++ sample projects in Visual Studio.Net Beta 2 and converted them with a simple recompile. The degree of VJ++ compatibility is impressive for a beta.
According to Microsoft, J#'s run-time libraries will remain frozen at the JDK 1.1.4 level; there are no plans to emulate later versions of the JDK. If J# catches on, it's likely that users will fill in the gaps over time. Microsoft considers JDK compatibility largely irrelevant. The current level supports Visual J++ projects, and whatever is missing from the JDK compatibility libraries is covered by the .Net framework.
J#'s interface to the .Net framework is solid, but not as seamless as C#. In particular, J# code cannot define new .Net properties, events, value types, or delegates. J# can make use of these language constructs if they are defined in an assembly written in another language, but its inability to define new ones limits J#'s reach and interoperability compared to other .Net languages.
Our experience with the J# beta was mostly positive, allowing for its narrowly defined mission and limitations. It gets high marks for VJ++ migration, and the final release is likely to render effortless the transplantation of even large VJ++ projects to the .Net platform. Although we think it's important to point out that J# adheres to an ancient cut of the JDK, we doubt that will matter much to most J# users. As for J#'s future as a .Net language, we'll wait and see. For .Net development, J#'s primary audience is hard-core Java coders who must target .Net, but who would rather live with J#'s limitations than switch to the more expressive and accommodating C#. But, despite our fondness for Java, nothing in this beta sways us from our preference for C# for .Net applications.
The bottom line
Visual J#.Net
Beta 1
Business Case: Visual J#.Net easily migrates VJ++ projects to the .Net platform and supports development of new .Net applications in the Java language.Technology Case: J# compiles or converts a surprising range of Java applications, making J# a potential Java competitor in the long run, as .Net and J2EE are.Pros:
+ Complete implementation of the Java language specification+ Includes clean-room JDK 1.1.4 classes+ Converter translates compiled Java code to .Net binariesCons:
- JDK support frozen at Version 1.1.4
- No language support for defining key .Net constructs- Compiled apps run only on WindowsCost: Not available Platform(s): 32-bit Windows systems running Visual Studio.Net Beta 2
