Let’s just say no conversion completes 100%.   You can make demos that do, but they are surprisingly challenging to write and normally aren’t very full-featured.  So, if every conversion needs a little work afterwards then SupportClasses represent areas where we have done that post-conversion work for you.  SupportClasses are C# source-code that we have written and include (when needed) in your project within a file called SupportClass.cs (imagine that).  This file can have multiple C# classes within it; the result of us trying to break the SupportClass into logical chunks.  This also helps us to only put the sections that you need into your project.  After a conversion completes, you will see a new C# project file (ok, sometimes more than one), a conversion HTML report, your new C# classes, misc. resource files and most likely a SupportClass.cs file.  What should you expect to find within the SupportClasses?  A small snippet of the Java-API implemented in C#.  The goal of a SupportClass is to exactly mimic the functionality found in the old Java-call but in C#.  This sometimes requires multiple .NET framework calls, or more parameters, or maybe an interface or two…  But, in the end, a SupportClass should look exactly how you would have fixed the conversion “errors” if we hadn’t.

 

This, of course, begs the question of why didn’t we implement SupportClasses for ALL of the additional work?  Right… No, seriously there are only a small number of cases where we can implement all of the changes necessary to have exact runtime equivalence in every variation of that snippet without massive (read: many megabytes) of code and years of time.  Maybe an example will help:  I have partially implemented a SupportClass for System.Property.getProperty(String property_name).  This is not something that is included in the JLCA because this relies on parsing user-string (the property’s name) and we try very hard not to get involved with user-string parsing. 

 

Example:

public class Properties {

  private IDictionary environmentVariables;

  public Properties() {

     environmentVariables = Environment.GetEnvironmentVariables();

  }

 

  public string GetProperty(string property_name) {

     string property = null;

     switch(property_name) {

        case "user.dir" :

            property = Environment.CurrentDirectory;

            break;

        case "user.name" :

            property = Environment.UserName;

            break;

        case "user.home" :

            property = environmentVariables["HOMEDRIVE"] + environmentVariables["HOMEPATH"];

            break;

        //... continued for a long time ...

     }

     return property;

  }

}

 

This actually works pretty well (if you can overlook my hard-coded strings, random concatenation without using StringBuilder, …) and around 12 of the “regular” environmental variables would easily map over in a class like this, but there are others that don’t map over as well (like the “java.version” environmental variable).  Most people would probably want the “jave.version” changed to check the runtime environment version of the .NET framework that is running their new C# application.  So do we look for a version of the JRE (maybe) installed on the machine and return that version?  Or would it be better to “correct” the user and return the version of the .NET runtime?  This gets even a little more complex when you look at the long list of “java.vm.*” variables that really don’t map to anything in .NET. 

 

Hopefully, now you start to see why every difference or post-conversion head-ache isn’t “solved” with SupportClasses.  Can we do more?  Of course!  J# did them all (up to JDK 1.1.4/VJ++) and a few years from now I might be giving you a very different answer but for now SupportClasses are the exception instead of the standard.  That said; if you have a great idea for where we should spend our time writing the next round of SupportClasses please leave it in a comment below. 

 

Now a bunch of you are looking at the fact I started saying (and showing an example of) why we can’t have SupportClasses for everything.  But then I stated that you should feel free to suggest areas for new SupportClasses…  Do I think that we have written every SupportClass that should be part of the JLCA?  No.  But I can’t think of too many areas that I would like to add them.  But as my disclaimer below says, I am fallible.  I do not claim to even assume I have thought of everything.   

 

Since there is code in this post:

Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Normal disclaimer:

This is my blog, my opinion, and as such is subject to my limitations.  Therefore, this posting is provided "AS IS" with no warranties, and confers no rights.