学习 Java 的 C# 开发人员,您可能忽略的最大差异是什么?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/2014709/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
C# developers learning Java, what are the biggest differences one may overlook?
提问by mrblah
For c# developers that are staring out to learn Java, are there any big underlying differences between the two languages that should be pointed out?
对于开始学习 Java 的 c# 开发人员来说,这两种语言之间是否存在重大的潜在差异需要指出?
Maybe some people may assume things to be the same, but there are some import aspects that shouldn't be overlooked? (or you can really screw up!)
也许有些人可能会认为事情是相同的,但有一些重要方面不应被忽视?(否则你真的可以搞砸了!)
Maybe in terms of OOP constructs, the way GC works, references, deployment related, etc.
也许就 OOP 构造而言,GC 的工作方式、引用、部署相关等。
回答by Jon Skeet
A few gotchas off the top of my head:
我的头顶有一些问题:
- Java doesn't have custom value types (structs) so don't bother looking for them
- Java enums are very different to the "named numbers" approach of C#; they're more OO. They can be used to great effect, if you're careful.
byteis signed in Java (unfortunately)- In C#, instance variable initializers run beforethe base class constructor does; in Java they run afterit does (i.e. just before the constructor body in "this" class)
- In C# methods are sealed by default. In Java they're virtual by default.
- The default access modifier in C# is always "the most restrictive access available in the current context"; in Java it's "package" access. (It's worth reading up on the particular access modifiers in Java.)
- Nested types in Java and C# work somewhat differently; in particular they have different access restrictions, and unless you declare the nested type to be
staticit will have an implicit reference to an instance of the containing class.
- Java 没有自定义值类型(结构),所以不要费心寻找它们
- Java 枚举与 C# 的“命名数字”方法非常不同;他们更 OO。如果你小心的话,它们可以用来产生很好的效果。
byte用 Java 签名(不幸的是)- 在 C# 中,实例变量初始化器在基类构造器之前运行;在 Java 中,它们在它之后运行(即就在“这个”类中的构造函数体之前)
- 在 C# 中,方法默认是密封的。在 Java 中,它们默认是虚拟的。
- C# 中的默认访问修饰符始终是“当前上下文中可用的最严格的访问”;在 Java 中,它是“包”访问。(值得一读 Java 中的特定访问修饰符。)
- Java 和 C# 中的嵌套类型的工作方式略有不同;特别是它们具有不同的访问限制,除非您将嵌套类型声明为
static它,否则它将具有对包含类的实例的隐式引用。
回答by jspcal
here is a very comprehensive comparison of the 2 languages:
这是两种语言的非常全面的比较:
http://www.25hoursaday.com/CsharpVsJava.html
http://www.25hoursaday.com/CsharpVsJava.html
Added: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp
添加:http: //en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp
回答by softveda
I am surprised that no one has mentioned properties, something quite fundamental in C# but absent in Java. C# 3 and above has automatically implemented properties as well. In Java you have to use GetX/SetX type methods.
我很惊讶没有人提到属性,这是 C# 中非常基础的东西,但在 Java 中却没有。C# 3 及更高版本也自动实现了属性。在 Java 中,您必须使用 GetX/SetX 类型的方法。
Another obvious difference is LINQ and lambda expressions in C# 3 absent in Java.
另一个明显的区别是 C# 3 中的 LINQ 和 lambda 表达式在 Java 中不存在。
There are a few other simple but useful things missing from Java like verbatim strings (@""), operator overloading, iterators using yield and pre processor are missing in Java as well.
Java 中还缺少一些其他简单但有用的东西,例如逐字字符串 (@"")、运算符重载、使用 yield 和预处理器的迭代器,Java 中也缺少它。
One of my personal favourites in C# is that namespace names don't have to follow the physical directory structure. I really like this flexibility.
我个人在 C# 中的最爱之一是命名空间名称不必遵循物理目录结构。我真的很喜欢这种灵活性。
回答by Sneal
There are a lot of differences, but these come to mind for me:
有很多差异,但我想到了这些:
- Lack of operator overloading in Java. Watch your instance.Equals(instance2) versus instance == instance2 (especially w/strings).
- Get used to interfaces NOT being prefixed with an I. Often you see namespaces or classes suffixed with Impl instead.
- Double checked locking doesn't work because of the Java memory model.
- You can import static methods without prefixing them with the class name, which is very useful in certain cases (DSLs).
- Switch statements in Java don't require a default, and you can't use strings as case labels (IIRC).
- Java generics will anger you. Java generics don't exist at runtime (at least in 1.5), they're a compiler trick, which causes problems if you want to do reflection on the generic types.
- Java 中缺少运算符重载。观察您的 instance.Equals(instance2) 与 instance == instance2(尤其是带字符串)。
- 习惯于不以 I 为前缀的接口。通常您会看到名称空间或类以 Impl 为后缀。
- 由于 Java 内存模型,双重检查锁定不起作用。
- 您可以导入静态方法而不用类名作为前缀,这在某些情况下(DSL)非常有用。
- Java 中的 Switch 语句不需要默认值,并且不能使用字符串作为 case 标签 (IIRC)。
- Java泛型会让你生气。Java 泛型在运行时不存在(至少在 1.5 中),它们是一种编译器技巧,如果您想对泛型类型进行反射,则会导致问题。
回答by Chris Jester-Young
.NET has reified generics; Java has erased generics.
.NET 已经具体化了泛型;Java 已经删除了泛型。
The difference is this: if you have an ArrayList<String>object, in .NET, you can tell (at runtime) that the object has type ArrayList<String>, whereas in Java, at runtime, the object is of type ArrayList; the Stringpart is lost. If you put in non-Stringobjects into the ArrayList, the system can't enforce that, and you'll only know about it after you try to extract the item out, and the cast fails.
区别在于:如果您有一个ArrayList<String>对象,在 .NET 中,您可以(在运行时)告诉该对象具有 type ArrayList<String>,而在 Java 中,在运行时,该对象是 type ArrayList;该String部分丢失。如果您将非String对象放入 中ArrayList,则系统无法强制执行该操作,并且只有在您尝试将项目提取出来后您才会知道它,并且转换失败。
回答by Sean
One thing I miss in C# from Java is the forced handling of checked exceptions. In C# is it far to common that one is unaware of the exceptions a method may throw and you're at the mercy of the documentation or testing to discover them. Not so in Java with checked exceptions.
我在 Java 的 C# 中怀念的一件事是强制处理已检查异常。在 C# 中,人们不知道方法可能抛出的异常是很常见的,而您受文档或测试的支配来发现它们。在带有检查异常的 Java 中并非如此。
回答by Pete Kirkham
Java has autoboxing for primitives rather than value types, so although System.Int32[]is an array of values in C#, Integer[]is an array of references to Integerobjects, and as such not suitable for higher performance calculations.
Java 对原语而不是值类型进行自动装箱,因此虽然System.Int32[]在 C# 中Integer[]是一个值数组,但它是一个Integer对象引用数组,因此不适合更高性能的计算。
回答by thecoop
No delegates or events - you have to use interfaces. Fortunately, you can create classes and interface implementations inline, so this isn't such a big deal
没有委托或事件 - 您必须使用接口。幸运的是,您可以内联创建类和接口实现,所以这没什么大不了的
回答by intoOrbit
The built-in date/calendar functionality in Java is horrible compared to System.DateTime. There is a lot of info about this here: What's wrong with Java Date & Time API?
与 System.DateTime 相比,Java 中的内置日期/日历功能非常糟糕。这里有很多关于此的信息:Java Date & Time API 有什么问题?
Some of these can be gotchas for a C# developer:
其中一些可能是 C# 开发人员的陷阱:
- The Java Date class is mutable which can make returning and passing dates around dangerous.
- Most of the java.util.Date constructors are deprecated. Simply instantiating a date is pretty verbose.
- I have never gotten the java.util.Date class to interoperate well with web services. In most cases the dates on either side were wildly transformed into some other date & time.
- Java Date 类是可变的,这会使返回和传递日期变得危险。
- 大多数 java.util.Date 构造函数已被弃用。简单地实例化一个日期是非常冗长的。
- 我从来没有让 java.util.Date 类与 Web 服务进行良好的互操作。在大多数情况下,两边的日期都被疯狂地转换为其他日期和时间。
Additionally, Java doesn't have all the same features that the GAC and strongly-named assemblies bring. Jar Hellis the term for what can go wrong when linking/referencing external libraries.
此外,Java 没有 GAC 和强命名程序集带来的所有相同功能。 Jar Hell是链接/引用外部库时可能出错的术语。
As far as packaging/deployment is concerned:
就打包/部署而言:
- it can be difficult to package up web applications in an EAR/WAR format that actually install and run in several different application servers (Glassfish, Websphere, etc).
- deploying your Java app as a Windows service takes a lot more effort than in C#. Most of the recommendations I got for this involved a non-free 3rd party library
- application configuration isn't nearly as easy as including an app.config file in your project. There is a java.util.Properties class, but it isn't as robust and finding the right spot to drop your .properties file can be confusing
- 以 EAR/WAR 格式打包实际安装并运行在几个不同的应用程序服务器(Glassfish、Websphere 等)中的 Web 应用程序可能很困难。
- 与在 C# 中相比,将 Java 应用程序部署为 Windows 服务需要付出更多努力。我为此得到的大部分建议都涉及非免费的 3rd 方库
- 应用程序配置并不像在项目中包含 app.config 文件那么简单。有一个 java.util.Properties 类,但它不是那么健壮,并且找到放置 .properties 文件的正确位置可能会令人困惑
回答by Turing Complete
Java doesn't have LINQ and the documentation is hell. User interfaces in Java are a pain to develop, you lose all the good things Microsoft gave us (WPF, WCF, etc...) but get hard - to - use, hardly documented "APIs".
Java 没有 LINQ,而且文档很糟糕。Java 中的用户界面开发起来很痛苦,你失去了微软给我们的所有好东西(WPF、WCF 等),但变得难以使用,几乎没有记录的“API”。

