C # is Java just a little bit worse

Both C # and Java are very good languages. They achieve similar goals in a similar way, although C # has more syntactic-related things than Java, such as the foreach keyword and some of the more pleasing extension/implementation architectures. Unfortunately, these improved rays are obscured by something that has been weakened. In this article, I'll compare the two languages and try to avoid going deep into the JVM and CLR layers.
Java: Indisputable essence of C + +
When comparing Java and C #, you cannot be aware of their many similarities, in part due to their common source: C and C + +. But when Gosling and his colleagues sat down to create Java, they not only learned the capabilities of C + +, but more importantly, they lost some of the unwanted features that made C + + easier to make mistakes and harder to learn. C # 's designers have added a lot of C + + features, and Java has added these features, but C # has not removed some of the worst features of C + +. The result is a language that still provides all the attributes for all, but the outcome is an internal conflict that is too complex.
The LAX syntactic defects
The most easily identified errors are flow control and syntax. C # provides the goto command as a mechanism to change the execution point of a program. Since Edsger W. Dijkstra published his "about go to statement of harm" in 1968 (go to Statement considered harmful). The goto statement causes the code to be difficult to debug and is difficult to be processed by the test tool.
In a different case, the operator overload also has a big problem, but the level is not the same. When "+" represents anything based on the type of operand, the function of the code is no longer transparent, and unexpected side effects can occur.
The weakening of C # in security
C # has a simple mechanism for marking areas of code as unsafe. In these insecure areas, Java and later C # have put in place security measures to prevent programmers from directly modifying memory locations and using dot operations, but these measures are questionable. When you use a high-level language with garbage cleanup, if you go down to the memory address layer, the object/memory is deliberately separated and confused. Errors can occur easily, debugging becomes a nightmare, buffer overflows are raised again, and the well-known security vulnerabilities in C and C + + appear again.
C # also allows simple access to native libraries on host systems. This and the non. NET object is similar to the functionality provided by the Java Native Interface (JNI), but it is more dangerous. JNI is designed to carefully restrict the interaction between Java code and native code and defined interfaces. NET makes it extremely easy to invoke native object files, and as a result, developers are unaware of the portability of their platforms out of the window during this process.
Integration of Soap
C #, and its larger extension. NET, has been tightly integrated with SOAP Web services. Soap is a good criterion for using XML to specify parameters and result values for remote procedure calls, but it is not the only way. Using external libraries for Web Services allows Java developers to easily change the style of their Web services to become SOAP, XML-RPC, or something that has not been invented. Of course, C # developers are always able to choose to use external libraries for SOAP Web services, but the tight integration of the SOAP standard creates more restrictions than it can do.