除了C#之外我懂得语言不多，主要是 VB(6)、上古C++(基于MFC编程)和Java，这里从语法层面列举一下C#相对于宇宙第一语言Java的优势。
1：空值判断
在Java里面null是不能作比较的(==null除外)，例如下面代码在Java里面会抛异常，在C#里类似的代码能正常运行，以Java里面每次使用if或者swich之前，最好先判断一下里面的变量是不是空值， 而写C#代码就没有这种顾虑。
2：字符串相等判断
在Java里面不能使用==判断两个字符串是否相等，要使用equals方法，但不要以为把==改成equals方法就完事了，还要考虑空值问题，例如以下代码很明显因为调用equals的对象是null会抛异常
在C#里面就没有这种顾虑了，==两头哪边是空值都没问题。但在Java里面int这些基础类型又可以使用==判断是否相等，因为Java不支持操作符重载，你想搞得String也统一使用==判断是否相等是不可能。但回过头来，判断一个字符串是不是null又不能用equals，又得用上==了。
Java的这个字符串判断方式连第三方组件都看不过眼，在jsp和MyBatisd的xml文件里面，都支持使用==判断两个字符串是否相等。
我做事比较粗心大意，总有忘记了要用equals，写成==的时候，导致相关代码总返回false。
3：失败的泛型设计
Java的泛型我现在还没有驾驭它的能力，我曾经试过通过泛型去定义一个把传入的Map转换成目标类型对象的方法：
就这样在C#看起来很平常的方法，在Java里面无法通过语法检测，编译不起来，真是连TypeScript都不如啊。
后来我还了解到，Java的泛型还有一个“类型刷除”的特性，无法在运行时获取泛型的类型，也就是说上面方法就算能通过编译也没有用，如果不增加额外的参数，则无法获取T的类型来创建新对象。
其实Java那个泛型我估计它自己都没有完全搞明白，举个例子：
这段代码d中的"abc"类型没有对上定义变量map时限定的Integer，但居然可以编译通过！
对应的C#代码是不可能通过编译的：
error CS1503: Argument `#1' cannot convert `string' expression to type `int'
Java的失败的泛型设计在整个框架里面随处可见，举个例子Java里面有个List<String>类型的对象list，要转换数组的话调用list.toArray()返回的居然是Object[]而不是String[]，要返回Stirng[]居然要写成list.toArray(new String[0])。这样的诡异特性在其他泛型相关的类里面也存在，而且还推陈出新，stream api里面，toArray、toList又换了另一种玩法。
另外Java的泛型还不能使用基础类型，例如不能定义List<int>要改成List<Integer>。
实际上通过上面例子我们已经可以看出，Java的泛型实际上是一个假泛型，本质上Java并没有泛型！Java里面List<Integer>和List<String>实际上就是List类型，是同一个类型，而且Java也允许直接定义List类型，List<Integer>和List<String>并不存在。Java的泛型实际上只是给编译器和IDE做类型检查的一个标识，做过Java泛型类型嵌套的朋友应该深刻体会到这一点，例如要把一个Json字符串转换成一个有泛型嵌套的对象 Object1{ListA:List<A>,ListB:List<B>}。估计其他基于JVM的语言Kotlin和Scala等也存在这种泛型设计上的缺陷。
4：过度设计的枚举enum
在C#里面enum的实际值是一个整数，在Java里面enum值被扩展成自身的类对象，这样Java的enum就比C#强大多了，跟类一样，可以随意在enum里面定义构造函数和方法，但不允许继承。
但不知道是不是因为不能直接转换成整数，Java的ORM(MyBatis)内置转换器都不支持enum类型映射成整数类型(但映射成VarChar可以)，我接触的Java程序员也很少用enum，在需要用到enum的地方都会用常量代替。估计其他基于JVM的语言Kotlin和Scala等的enum也只能沿用这种设计TG：li9047
