Euchre Conversion to Android

I just started converting my Windows Euchre game to an Android app, and there's already some things I miss about C#.

1. Operator overloading
1. In C# I can create functions to overload the =, ==, <, >, and other operators, so that I can do things like if(card1 < card2)
2. In Java I have to create functions like .set, .equals, .lessThan, .greaterThan, etc. So I have to now change all of the == to .equals in my code, and so on with the other operators. Now I have to do if(card1.lessThan(card2))
2. set/get Functions
1. In C# I can do something like this:
   public string name
   {
       set
       {
            this.m_name = value;
        }
        get
        {
            return this.m_name;
         }
    }
   
   Then access the variable like this:
   
   player1.name = "Randy";
   and
   name = player1.name;
2. In Java, I have to create 2 functions, setName, and getName, then have to access like this: player1.setName("Randy"); and name = player1.getName();
3. Native Data Types: This one I've run into before while programming with Android/Java... native data types have different names in C# and Java. And I'm so used to using C/C++/C# that I often find myself using the wrong name.
1. In C#, true/false values are bool, and text values are string
2. In Java, true/false values are boolean, and text values are String (capital S)
1. This is because (as I explain in more detail in #5) strings in Java are objects, whereas they are a native data type in C#.
4. Naming Convention
1. In C#, generally variables start with lowercase letters, and functions and classes start with uppercase letters
2. In Java, generally variable and functions start with lowercase, and only classes start with uppercase.
5. String comparison: Because there is no operator overloading in Java, and strings in Java are actually objects not a native data type, this is different too
1. In C#, I can say if(string1 == string2) and it will compare them.
1. This is partly because strings are a native data type in C#. But even if they weren't, you would have the ability to override the == operator.
2. In Java, I have to say if(string1.equals(string2)) to compare them
1. This may not seem like a big deal, but doing string1==string2 is legal, and a valid statement, but it likely will not return the result you are looking for. This will check to see if the two variables are in the same memory location, NOT whether or not they contain the same information.

These things may not seem like a big deal to someone who is not doing the programming. A few extra letters here or there, some difference in lowercase vs uppercase, some extra functions here or there... 

But when you're dealing with literally thousands of lines of code which need to be translated from one language to another, this is a big deal. And testing is going to be a big deal too, because I'm sure that I'm going to make some translation mistakes somewhere. 

Luckily the IDE I'm working with is VERY good at pointing out possible logic errors as warnings (like the string1==string2 thing) so that will definitely help. But this may take a while, as I expected.

And although the IDE is good with logical warnings, #4 becomes a problem with this IDE because the auto fill function in the IDE is case sensitive. So if I am looking for player1.getName() and start typing player1.GetName(), the auto fill will not find getName(). (Or if it does find it, it will take a while to find it.)

Sorry for the rant, I'm just not a fan of Java and never have been.