For the first real JLCA post I thought I would start off with everyone’s favorite HelloWorld. 

 

Java-version:

public class HelloWorld {

    public final static String message = "World";

   

    public static void main(String[] args) {

        System.out.println("Hello: " + message);

    }

} 

 

Quick pass through the JLCA (Within VS 2003; FileàOpenàConvert.  Convert a directory of files.  Point to the directory containing HelloWorld.java and convert the project as a Console application.) gives us:

using System;

public class HelloWorld

{

            public const System.String message = "World";

           

            [STAThread]

            public static void  Main(System.String[] args)

            {

                        System.Console.Out.WriteLine("Hello: " + message);

            }

}

 

 

While we are on the simple stuff let me point out some obvious items that might get lost in more complex examples.

 

  • public static void main is converted with the corresponding attribute [STAThread].  This tells Visual Studio which is the actual “Main” or entry point into your code.  This can cause problems if you have the convention of including a main method in each class (or just more than once).  C# will force you to identify the Main (notice the case change) that you want run when the user runs the .exe (assuming this is a console or GUI app.)
  • C# doesn’t have “static final” in the way Java-language programmers are use to.  You now have the option of const, readonly, putting the variables in an enumeration, ...  Each of these are well documented (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfModifiersKeywords.asp) but can still be a little confusing to the new C# developer (like not being able to use readonly variables within the case statement of a switch block.)
  • We also get lots of comments on the user’s ability to modify the output of the JLCA.  Such as “Can I get string variables instead of System.String?”  The short answer is not really.  We have _started_ to add some customizability to the command line version of the JLCA (ie. running the JLCA from the VS command prompt instead of from the Wizard with the IDE.)  This gives the user the ability to decide whether they want the JLCA to convert get/set methods to C# properties or leave them as get/set methods.  There is also the possibility of using the Extensibility Kit (more on that below).  But the you are still pretty limited.  If you have specific things you think just HAVE to be changeable next time let me know and we will look into adding that feature.
  • The JLCA will only convert compilable (should be a word.  Meaning: able to compile.) Java-language source.  For example, if you switch void with final above the JLCA will not even parse the main method.  The old garbage-in garbage-out. 

 

 

The Extensibility kit:  Disclaimer!!! This is a separate tool developed independently from the JLCA and is not owned by MS.  This mean MS doesn’t have any control over its development or marketing strategy.  I don’t know numbers except that I don’t believe it is free.  The 3rd party that built the Extensibility tool is the same 3rd party that wrote the engine to the JLCA.  I do work closely with this company on the JLCA but have only played with the Extensibility Kit.  Ok enough of that.

The theory is: the Extensibility kit allows the user to create custom mappings for the JLCA.  That is, you can override and/or extend the JLCA’s conversion knowledge to cover areas not previously covered or maybe not covered to your liking.  A good example would be Layout Managers (another day’s topic for sure).  Everett doesn’t support Layout Managers so these can’t be converted from your Swing application.  If you wanted to you could buy (or write) a 3rd party Layout Manager DLL in .NET and using the Extensibility kit change the mapping of your Swing app. to use this newly introduced DLL.  You could also use the Extensibility kit to modify an existing mapping.  If your ever productive dev team has their own special collections package and you want to map all Lists to your SuperList implementation then the Extensibility kit could to that for you at conversion time.  And that is Extensibility for the JLCA.  Oh, one little side point.  The Extensibility Kit creates new mapping DLLs.  Those DLLs are used in the conversion process by the JLCA (loaded in addition to the default mapping DLLs).  You need the kit to create the DLLs, not to run them.  Just to be clear.

 

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.