|
|
One PM floating down the stream. What? Did you expect a rock parting the waters?
-
I will apologize again for this post taking me forever to write.
When I converted the Apache project I ran into a fundamental or more precisely a philosophical problem; that, unfortunately, can not be fixed by the JLCA. The problem is whether it is better to keep to the original structure or migrate that structure to the .NET structure. While hierarchy differences are always some of the most difficult issues to resolve, this wasn’t an issue until I made it one. The Apache project was almost completely self-contained. The project had its own interfaces and super-classes. The problem was that I started to convert the classes that implemented (for example) Apache’s XMLDocument interface into classes that extended .NET’s concrete XmlDocument class. As you can imagine this caused a number of classes to now “have” multiple parent classes which I had to resolve, not to mention duplication of code (since Apache’s sub-classes had implemented the XMLDocument interface). This I kind of expected although it turned into more of a headache than I ever would’ve imagined. What I didn’t expect was the thousands of now incorrect virtual, overrides, and new keywords that the JLCA had inserted (assuming that I would continue to try and use Apache’s hierarchy) which I now had to fix. These were unbelievably tedious, and I came very close to not finishing the conversion a number of times. What makes these so bad is that they are easily covered by “real” compiler errors and so they seem to jump out at you continuously and make keep you from fixing all of them once and for all. Plus they have a cascading effect that goes down the hierarchy, so as you “fix” one, you break each of that class’s sub-classes. And so on, and so on…
I still believe (take this with a grain of salt since I am still a high-level “programmer”) that it is best to be as close to the bare-metal as possible. What I mean is that I would rather convert the XML libraries to use .NET’s built-in support than re-implement this myself (or use Apache’s implementation of it). But this did end up making a lot more work. I have to admit that the JLCA does not handle this aspect of conversion very well. The JLCA tries its best to keep the exact form/function of the Java code which, in this case, was at odds with what I wanted my C# code to be. I think this is a rather extreme example of this problem since all of Apache’s XML functionality is present in .NET’s XML libraries so just about every class I ran into had to be changed to accommodate this. What I ended up with is a programmatic interface that pretended to mirror Apache’s XML interface on top of .NET’s XML libraries. This would’ve been a lot faster to just implement this interface from scratch instead of pruning all of the original Java implementations out of the migrated code one at a time. I actually created almost an exponential growth of errors as I went about my restructuring!
While I can justify this as a great experiment that I learned a lot doing (I love my job!), from an Enterprise view this should stand as a warning. The JLCA, or any tool for that matter, is just that: a tool. If, at any point during the migration, you find that you are in a similar situation (exponential error growth, cutting massive amounts of the old Java logic that is now covered in .NET, …) you should stop and re-evaluate if it wouldn’t be easier to start writing C# from a blank file. This isn’t to say that you have to choose one path or the other, if I was writing a real Enterprise application that happened to use this set of Apache’s libraries I could easily convert the rest of the application with the JLCA and only implement a similar interface on top of .NET’s libraries as I suggested above (or you could migrate the rest of the app and then modify the calls that use to use Apache’s libraries to use .NET’s and cut the interface out completely.)
I would like to point out that I am not saying the JLCA is not useful, just that it isn’t the only option and, although it pains me to admit, it is not always the best option. Besides rewriting there is also J#, interoperability, and other 3rd party tools that could be used instead or in addition to the JLCA. The idea is to choose the right approach for your situation. This is an aspect that I don’t think a lot of people think about; especially the J# option. J# has full access to the .NET platform and the J# DLLs work just as smoothly with a C# project as any other .NET DLL. Areas of your application that limit themselves to the JDK 1.1.4 functionality or just fit within J#’s domain would be converted at almost 100% instead of the JLCA’s 85-90%. This could save you a lot of time by converting component of you application individually with whichever tool was easiest. I think that I will try to focus the next couple of posting on this aspect of conversion instead of the more technical issue-fixing side. Hopefully I will be able to get back into my weekly posting schedule again!
|
-
|
Sorry that I haven't posted anything in a month! I have been running training and visiting customers, but I should be back into the weekly posts soon (promise). As a teaser, I have put all of the airline time to use converting the Xerces project from Apache. I am writing up my walkthrough of this conversion and should have that posted shortly.
|
-
One of the new wiz-bang features of the JLCA version 3.0 is support for converting the Swing package to .NET. This numerically performs great, but there is one hole that brings almost every conversion to a screeching halt: Layout Managers. The .NET framework doesn’t currently have a concept of Layout Managers that a Java Programmer would recognize. You can anchor controls which can approximate BorderLayout and FlowLayout is kind-of the default in C# but what about the others? Remember the phrase up-a-creek? Currently your options are limited to not using LayoutManagers in your Java code (like that is really an option) or having LayoutManagers implemented on the .NET Framework. For those of us that don’t really have the time or inclination to re-code Gridbag in C# there are 3rd parties that sell C# versions of all the LayoutManagers. For those of us that find our money more limited than our time check out: http://www.csharphelp.com/archives/archive7.html for a good starting place. Matthew Johnson wrote a short article on LayoutManagers in C# and generously provides implementations of Flow, Grid, and Border Layouts. If your Swing application wasn’t overly complicated this might be all that you need. Those that went all out with GridBagConstraints can still use Matthew’s foundation classes as a starting point for your own LayoutManagers. (Hmm, sounds like a good excuse to start a small series of posts one on each of the missing LayoutManagers… We’ll see what my schedule is like in the next few weeks.)
The JLCA will work with these new LayoutManager right? Sorry. Oh wait, did you want something more than the short answer? You will convert your application as usual, receive LayoutManager errors and then “quickly” fix them by changing the non-converted Java calls to C# calls into your newly bought/written .NET LayoutManagers. Shouldn’t the tool do this automatically? Maybe. This ties back to not supporting 3rd party any-things that I mentioned in my introduction to the JLCA. But (you knew there had to be a ‘but’ since I wrote this post) you can make your life a little easier if you plan on running the conversion multiple times. I.e. you only have to do the work once instead of after every conversion. How you ask? Well it is all about the difference between 3rd party libs and your source code. Why can the JLCA convert your code but not that nifty logging utility? The simplest of answers; you have the Java-source to your code. How does that help us if the LayoutManager source is in C#? It doesn’t, but if you created (I propose this being done programmatically) a tool that took your C# code and created Java stubs of the public methods and members (also the protected ones if you extended any of the LayoutManagers) you would have Java code. Then you refactor your imports from the standard javax.swing.XYZ to my.stub.XYZ and the next time you convert the JLCA will convert your source plus your stubs. You have effectively fooled the JLCA into thinking you have the source to these LayoutManagers. Assuming you used the same package structure and class names as the C# you can now overwrite the converted stubs with the actual C# implementations and bingo: conversion without the LayoutManager errors. Sounds like a crap-load of work huh? Well I did warn you it was really only really an option if you planned on doing multiple conversions. At that point you could justify the up-front cost by not having to repeat the post-conversion work every time. Is this the only solution? Not by a long shot; remember the good old Extensibility Kit? This is of course the poster child case for that tool. And while I haven’t purchased any of the 3rd party toolsets I am sure they have their own creative ways of dealing with this tedious issue.
Completely off topic, if any of you haven’t seen the new movie Monster yet I would suggest you wait for the video store. I would say that it was the best acting I have ever seen in a made-for-TV movie. Honestly, the acting is very good. Charlize Theron and Christina Ricci do great jobs. It’s just that the story lacks drive. A friend summed it up by saying that the movie “lacked climax” (and before you think this a bad pun on the lesbian scenes; it was a female friend and her mind isn’t in the gutter.) A different friend said that it was the first time he had paid to see a documentary. No one expected a fiery, explosion-filled ending, but I left the theater wondering where they had wanted to go with the movie, and why hadn’t we gotten past the start line.
|
-
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.
|
-
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.
|
-
Ah, the calm before the storm… At least I hope there will be a storm. My team has just release a beta and I am trying to be patient as I wait for *real* user feedback. Let me step back a second and allow myself to introduce… myself. (1: I like movie quotes.) My name is Travis Bright and I’m the Program Manager for the Java Language Conversion Assistant (JLCA). Don’t know what the JLCA is? The short version: JLCA converts Java-language source code into Visual C#; making it easier for a developer to move to the .NET platform. If you are interested I have links at the bottom to a couple of press announcements that also include instructions on joining the beta.
Ok, back to the storm which sounded a lot more interesting before I had you read the condensed version of the professional life of a guy you have never met (me). Any release is wonderful, a milestone to smile-in-passing and know that all of the hard work was worth it. But beta is even more fun. JLCA doesn’t run an alpha program, so beta is the first real measure of a version. Sure, we have some of our partner companies try it out and give us their feedback (which is pure gold in my world) but pre-beta JLCA bits get to less than 20 companies. The first week, our beta touched an order of magnitude more customers. Which, living for customer feedback, is guaranteed to keep a smile on my face. As the bugs come in (hopefully this is where the storm starts) I get a couple of lines on what my customers think about the tool. Not to mention the improvement to the overall product. I can’t lose. Even duplicate bugs give me a great idea of the areas customers are exploring. One thing is sure: language converters are evolutionary products. And I don’t mean that they fundamentally change the world. I mean they take revision after revision to come to fruition. This is made even more challenging by the fact that neither the Java-language nor Visual C# (nor underlying .NET framework) is static. And trying to keep a bridge suspended between two moving points insures my job is never boring!
Why a new BLOG? Everyone has to have one right? No, actually. I have seen a few lonely comments about the JLCA and even more questions about migrating JSP, EJBs, … to .NET and wanted to create a compiling area for all of these. I fancy myself a bit of a developer and routinely write code to migrate. This gives me a great feeling of understanding. I _think_ that I know the normal issues and problems with running migrations, but the only way to be sure is to have real customers tell me. So, I will try to post interesting information on interoperability (yes I like when everyone can play together*), conversion, helpful (hopefully) tips from my recent migrations, and whatever else had caught my interest. Thanks for reading my FIRST POST!
*No, I do not think myself the guru of interop. that Simon G. is, but it is a wonderful model that actually works in practice!
Quick note: I will slip and say “my team”, “my customers”, or “my product”. I think that falls into the _motherly_ aspect of being a PM. I feel that I have responsibility over every part of the JLCA which gives me an improper since of ownership. If anything, the MS JLCA owners are my wonderful Dev and QA leads. Please take possessives with a grain of salt.
Promised links:
http://www.techweb.com/wire/story/TWB20040122S0003
http://www.infoworld.com/article/04/01/21/HNbetajlca_1.html
As with most BLOGs, this is my personal view of the world.
This posting is provided "AS IS" with no warranties, and confers no rights.This posting is provided "AS IS" with no warranties, and confers no rights.
|
|
|
|
