One nice features of the JLCA is that it converts javadoc-style comments into the corresponding .NET XML comment. Well, a new tool was released a few weeks ago that can take .NET’s XML documentation and create nice looking files. It is called Sandcastle, and is currently a CTP download. It can create .html files from the source code, which can be processed with the HTML Help Workshop to generate a .chm file. It also has a Visual Studio Add-in that makes the process really easy.
You can download the CTP here, and read all about it in the Sandcastle team blog.
We have been aware of that fact for a while, but we tried anyway - and it doesn't work. The main issue is that the components were implemented separately, and respond to different object hierarchies. Windows Forms receive components that extend the System.Windows.Forms.Control class, while Java containers receive objects that extend from javax.swing.JComponent. This causes an incompatibility, as the code will not even compile when you add an object from the "other" hierarchy, as shown in the following example. Trying to compile this code:
JFrame frame = new JFrame("HelloWorldSwing");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
...
ComboBox cb = new ComboBox();
frame.getContentPane().add(cb);
will give you this compilation error:
Cannot find method 'add(System.Windows.Forms.ComboBox)' in 'java.awt.Container'
The exact same thing happens when you try to add a J# Component to a Windows Form. There are of course technical reasons for this, like the fact that the J# runtime was developed independently, thus components expect a different environment when being drawn, and that it uses a different event handling mechanism (based on Java instead of .NET). But it is a bummer not being able to use a JTable and, for example, a DateTimePicker side-by-side.
A colleague of mine passed me this great link, which details the differences in API support between the different versions of Java, including J#. This is a great resource if you're considering moving your Java application to J# 2005, as it will tell you exactly which packages will give you a headache.
It is also worth mentioning that if you're working with Visual J#, the Supplemental UI Library is a must. This library includes an implementation of several Swing classes and packages, plus some support for additional classes added to the java.util.* package since JDK 1.2 (remember that J# supports the JDK up to 1.1.4). This Supplemental Library is already included in the Microsoft Visual J# Version 2.0 Redistributable Package.
And don't forget that there's a Visual J# 2005 Express Edition as well!!
An version of the JLCA training is still available online from Microsoft's website here. It has a chapter on the JLCA Companion, and also includes a chapter on migrating BEA's technologies.
Check it out.
SWT is a commonly used Java GUI framework, brought to the masses by the Eclipse project. Every once in a while there is customer that wants to migrate from a SWT-based application to C# using the JLCA, but so far this conversion required a significant effort in order to build the necessary infrastructure.
Well, now there's hope. I just noticed that the good guys at ICSharpCode have a version of SWT for .NET, called the Sharp Widget Toolkit (SharpWT or #WT). With this library and the JLCA Companion, we should be able to automate the conversion of a significant portion of SWT-based application, and get them up and running on .NET very quickly. Based on their previous work, the SharpWT library should be very high quality - they also developed the #ziplib library, to which we've often converted the java.util.zip.* classes, and other projects you can check out on their website.
So, there you have it - there is hope for SWT to .NET migrations. ;o)
The recording for the webcast I gave last week, titled "Proven Techniques to automatically convert your J2EE code to C# and .NET", is now available! You can check it out here.
The webcast is mostly about the techniques we have developed here at ArtinSoft to succesfully peform migration projects using the Java Language Conversion Assitant and the JLCA Companion. When performing J2EE to .NET migration there are several things that you have to keep in mind - for example, J2EE applications often rely on third-party components. These components are usually not migrated automatically by the JLCA, since there is no way to include all these APIs in it. By using product like the JLCA Companion, you can automate the migration of these components, siginificantly speeding up your migration efforts by reducing the amount of manual work you need to perform. In the webcast, we show you a smalll demo of the JLCA Companion, how it works, and how it can be used in your migratino projects.
In the web cast, we also cover:
- An overview of the nxt initiative by Microsoft
- An overview of ArtinSoft and ArtinSoft's migration expertise
- Why should ISV consider automated software migration when moving to a new platform
- A summary of various Java to .NET concepts
- A detailed description of the migration process followed here at ArtinSoft, using the JLCA Companion
- And, finally, we have two live demos, one about using the JLCA Companion, and another one about a complete migration of a web application that is accomplished in just a few minutes!!
So, check it out, and enjoy :-).
I will be giving a live webcast next week!!
The webcast is titled Proven Techniques to automatically convert your J2EE code to C# and .NET, and it is as part of Microsoft's nxt initiative, aimed at moving ISVs to Microsoft's platforms.
The webcast is next Tuesday at 10:00AM PST. You can register for the event here: Event Link