At first glance, you cannot help but notice the similarities between Java and C#. Looking even closer, you will notice that the similarities do not stop at the surface. The question is how can you use these language similarities to your advantage? Suppose you had an application that was already written in one language, and wanted to port it over to the other? Just how complicated would it be to convert an entire project from C# to Java - or the other way, from Java to C#? That was a question I recently had to answer, and you will be happy to know that the whole process is rather straightforward. Besides some simple restructuring and keyword replacement, the heart of your code will remain unchanged.

Planning Ahead
When Infragistics decided to build a charting engine using the .NET Framework, we had also hoped that in the future the same code could be used to provide a Java-based engine. From Day 1, the goal was simple - write a charting engine in C# that could later be ported to Java. This meant that instead of having two teams of developers working on writing the same code in two different languages, it could be coded once and then simply converted from its initial C# implementation to a Java implementation. Since the languages are so much alike, most of the changes made during the conversion were superficial, and did not affect the logic of the engine. In the end, after making some simple changes to the original C# code, we ended up with two identical charting engines - one for use with the .NET Framework, and the other for use with J2EE.

Because I was originally a Java programmer, picking up C# was a snap for me. In addition, it was easy to identify the features of C# that are not available in Java. The charting engine was written with some of these features in mind: in order to make the conversion to Java a little easier, we avoided using some of the C#-specific features. For example, in Java you can have only one public class in a file, and the filename must be the same as the class name. Following this rule for C# means one less thing to worry about during the conversion process later on. The best part is that you are not losing any functionality. You just end up with a few more files in the end.

Although working with these constraints may slightly increase the development time and effort for the initial implementation, the time spent is easily gained back in the time saved in the conversion process. This holds true when moving from C# to Java, but since C# contains the additional features, it is less of a factor when converting from Java.

The Conversion Process
Once development on the C# project was completed and the engine was fully tested, we began the conversion to Java. When converting C# code to Java, quite a few changes need to be made inside of each file, but they are all very straightforward. Since Java doesn't have properties, each property needs to be split up into its composite getter and setter methods. This process is very tedious, but since it doesn't require a whole lot of thought, it can be completed rather quickly.

All metadata attributes can be removed from your code since there is no equivalent in Java. Since most of these attributes are used for design-time features that are not available in Java, you can safely remove them, without worrying about breaking your code. If your class extends another class, or implements an interface, you will need to change the C# ":" to either the "extends" or "implements" Java keyword.

Namespaces can be changed to packages, and internal access modifiers need to be removed. Since there is no concept of "internal" in Java, you will undoubtedly end up with a few extra public members. At the top of each file, you will also need to change the "using" keyword to "imports", and identify the Java package that corresponds to the referenced .NET Framework namespace. It might take some time to locate the correct package, but you will find that once you do locate it, many of the classes are very similar, if not the same as the initially referenced .NET Framework namespace. Table 1 shows some useful mappings of the .NET Framework to Java.

 

Take a look at the two classes shown in Listing 1. At first glance, they look identical. Looking a little closer, you will notice the subtle differences between the two. For one, C# uses the Pascal Casing standard for public members, whereas Java uses the Camel Casing standard. With a couple of minor changes, you can go from C# to Java, or vice versa.

As you can see, if you know Java, it's not very difficult to read and understand code written in C#. After taking a couple minutes to note the minor differences, you can easily write your own classes in C#.

One concept missing from Java is the Enum. Even though Java does not have its own Enum type, Enums can easily be simulated using classes with static members. Again, this is pretty straightforward, and can be done by simply creating a new class with the same name as the Enum and adding static fields for the Enum values. Making the fields final will ensure that the values cannot be changed. By implementing your own Enums in Java using this technique, all of your code, aside from the Enum definitions themselves, will remain unchanged.

Because Java and C# have so much in common, instead of taking months of development time we had a fully functional Java charting engine in a matter of weeks. This beat even our own estimates of the time it would take for the conversion. Not only did porting the code reduce the amount of effort needed to produce a Java counterpart for our .NET chart, but we ended up with two identical implementations of our charting engine. Since the functional code is basically identical for both versions, maintenance is a breeze. In most cases, code can be changed in one implementation, and then simply copied and pasted into the other.

What's the Difference?
Plain and simple, one of the biggest differences between Java and C# is the design-time support. The .NET Framework makes it pretty simple to create editors for your properties. However, the PropertyEditor framework in Java is a little less robust. Java does not have built-in support for editing complex properties at design time, which means that if you are building a component that will be used at design time in an IDE, you'll need to add some extra code to your project. Since there is no built-in editor for complex properties in Java, PropertyEditors need to be built for each object. The problem is, a PropertyEditor in Java can return only one code fragment, which initializes the object. Because of this you will need to create special methods, or constructors, that have parameters for each property that can be set on your object. Just be warned, the more complex your property, the harder it will be to read the code produced by the editor.

Conclusion
Besides the differences in design-time support for IDEs, the C# and Java languages are so similar that there really is no learning curve when going from one to the other. By taking the learning curve out of the picture, there really are no hurdles left if you decide to switch languages. That translates into a quick and easy transition from Java to C# and the .NET Framework. Instead of worrying about learning the syntax for a completely new language, you can focus on learning the advanced concepts of that language.