5 Replies Latest reply on Feb 4, 2009 6:47 AM by Tim Fox

    .NET Client Conversion

    Clebert Suconic Master

      As the other developers know, I'm doing the .NET conversion for the Client library.

      To get things started I created my environment on both Windows and Linux.

      For LInux, I installed an IDE called monodevelop. (Both Ubuntu and Fedora will have it on the respective package Managers). MonoDeveloper will be able to open the same project files managed by Visual Studio.

      For Windows, I'm using KVM. (KVM is faily simple. The only real difficulty is to enable virtualization on the computer BIOS :-) )

      On Windows, besides Visual Studio, I have installed NUnit for Testcases and http://ankhsvn.open.collab.net/ for SVN integration on Visual Studio.

      C# and Java are very similar. There are few common changes I already identified though:

      - Capital Convention on name methods.
      Java will aways use lowerCase as the first letter, while C# Capital on the first letter for methods.

      - Properties Get and Set Methods
      C# introduces a new syntax for property get and propert set. Instead of regular methods, .NET programs will have a special syntax for properties:

      
       public int Length
       {
       get;
       set;
       }
      


      On the code above, the get and set implementation is done automatically. You could also add code if you need extra behaviour.

      I don' t have an opinion about this yet. Maybe I should keep property methods as methods during the conversion, so it would be easier to keep code similarity between Java and C#. I will make my opinion about this as I go, and I will keep you guys posted.


      - On the testcases, I'll use a super class for everybody to make the conversion easier. In C# you call Assert.areEquals instead of assertEquals methods. I''m adding those definitions on a super class to make life easier on the conversion.


      I"m still going through the conversion. From now on it should be faster.

      I want to keep feeding this thread with more findings, and write a WIKI & blog about my findings when I have more information.

      Also, please... share you experience on this thread if you have any experience about converting Java classes as C#,

        • 1. Re: .NET Client Conversion
          Clebert Suconic Master

          An Update:

          For testcases, It's better to run your tests on the NUnit directly. Just open the DLL generated by the build project, and you should see all the tests results.

          On Visual Studio, you will need to download a thirdpary plugin provided by TestDriven.NET. It's free for open source developers.


          On MonoDevelop, you need to open the Tests View, and run the tests from there.

          I will later provide ant integration.

          • 2. Re: .NET Client Conversion
            Clebert Suconic Master

            There is an issue on the SimpleString hashCode calculation.


            This loop:

            public int hashCode()
             {
             if (hash == 0)
             {
             for (int i = 0; i < data.length; i++)
             {
             hash = 31 * hash + data;
             }
             }
            
             return hash;
             }
            
            



            Is eventually overflowing MaxInt, and that's considered an Exception in C#.

            I'm looking to how hashes are calculated in mono, and I will try using the same function.




            • 3. Re: .NET Client Conversion
              Tim Fox Master

               

              "clebert.suconic@jboss.com" wrote:
              There is an issue on the SimpleString hashCode calculation.


              This loop:

              public int hashCode()
               {
               if (hash == 0)
               {
               for (int i = 0; i < data.length; i++)
               {
               hash = 31 * hash + data;
               }
               }
              
               return hash;
               }
              
              



              Is eventually overflowing MaxInt, and that's considered an Exception in C#.

              I'm looking to how hashes are calculated in mono, and I will try using the same function.




              It should be the same to wrap it back to -MAX_INTEGER if .net doesn't do that automatically

              • 4. Re: .NET Client Conversion
                Jesper Pedersen Master

                Just my $0.02 as I have done this a couple of time - plus I wrote some of the Mono.Security.dll.

                * Use properties

                .NET developers find it very strange if simple attribute assignment should be handled through method calls. If there are additional checks/functionality involved with the assignment put that in the set{} method.

                Of course there is a fine line when something should be moved a method - but as a general rule I found that properties are used when you operates on data that keeps the state of the object - where methods are used when you execute functionality.

                * Use capital on the first letter for properties/methods.

                Yep - this is different from Java ;) Small note, .NET doesn't (typically) expose any properties/methods that starts with Get/Set...

                * Mono tool chain works great

                I used Mono + NAnt + NDoc + NUnit for my work - and it worked great. I basically built a development environment as I would have done when coding Java. Of course the work I did on Mono.Security.dll was done on their branch following their rules. Deployment was .dll files that were then used by .NET developers using the M$ environment.

                (And yes, the development was done because 1) M$ security dll didn't contain the needed functionality 2) license issues 3) support multi-platform development)

                HTH - feel free to ask :)

                • 5. Re: .NET Client Conversion
                  Tim Fox Master

                  When you start to convert Java to .NET you should not take the Java code from trunk, but take it all from the same revision. Make a note of this revision. (You could actually svn copy for this)

                  Then later on, when you have finished. We can do a diff of TRUNK against that revision and re-apply any changes in the Java to .NET.

                  If you take from trunk, we won't be able to do that.