C # developers learning Java, what are the biggest differences you can ignore?

For C # developers looking to learn Java, are there any significant differences between the two languages ​​that need to be specified?

Perhaps some people may consider things the same, but are there some import aspects that cannot be ignored? (or you can really mess up!)

Perhaps, from the point of view of OOP designs, the way GC works, deployment related links, etc.

+72
java c #
Jan 06 '10 at 17:07
source share
16 answers

A few heads from the head:

  • Java has no user-defined value types (structs), so don't worry about them.
  • Java enumerations are very different from the C # number name approach; they are more OO. They can be used to great effect if you are careful.
  • byte Java signed (unfortunately)
  • In C #, instance variable initializers are run before the base class constructor; in Java, they run after it is executed (that is, immediately before the constructor body in the "this" class)
  • In C #, methods are closed by default. In Java, they are virtual by default.
  • The default access modifier in C # is always "the most restrictive access available in the current context"; in Java, this is batch access. (This is worth reading on specific access modifiers in Java.)
  • Nested types in Java and C # work a little differently; in particular, they have different access restrictions, and if you do not declare a nested static type, it will have an implicit reference to an instance of the containing class.
+101
Jan 6 '10 at 17:13
source share
+20
Jan 6 '10 at 17:13
source share

I am surprised that no one mentioned properties, something completely fundamental in C #, but missing from Java. C # 3 and above also automatically implemented properties. In Java, you should use methods like GetX / SetX.

Another obvious difference is LINQ and lambda expressions in C # 3, which are missing in Java.

There are several other simple but useful things missing from Java, such as verbatim (@ ") strings, operator overloading, and iterators using output and preprocessors are also missing in Java.

One of my personal favorites in C # is that namespace names should not follow the structure of a physical directory. I really like this flexibility.

+15
Jan 06 '10 at 20:37
source share

There are many differences, but they come to my mind:

  • No operator overloading in Java. View your copy. Equalizer (instance2) compared to instance == instance2 (especially with strings).
  • Used for interfaces that do not have a prefix with I. Often you see namespaces or classes, suffixes with Impl instead.
  • Double locking check does not work due to Java memory model.
  • You can import static methods without their prefix with the class name, which is very useful in some cases (DSL).
  • Switch statements in Java do not require a default, and you cannot use strings as case labels (IIRC).
  • Java generators will annoy you. Java generators do not exist at run time (at least in 1.5), this is a compiler trick that causes problems if you want to reflect common types.
+10
Jan 6 '10 at 19:39
source share

.NET has updated generics; Java erases generics.

The difference is this: if you have an ArrayList<String> object, in .NET you can indicate (at runtime) that the object is of type ArrayList<String> , whereas in Java, at runtime, the object is of type ArrayList ; the String part is lost. If you put String objects in an ArrayList , the system cannot provide this, and you will only know about it after you try to retrieve this element from the list and the execution fails.

+8
Jan 06 '10 at 17:20
source share

One thing I miss in C # with Java is forcing checked exceptions to work. In C #, it is very common that no one knows about the exceptions that a method may throw, and you are at the mercy of documentation or testing to detect them. Not so in Java with checked exceptions.

+6
Jan 6
source share

There are no delegates or events - you need to use interfaces. Fortunately, you can create classes and implementations of the interface internally, so this is not so important.

+4
Jan 06 '10 at 17:16
source share

Java has autoboxing for primitives, not value types, therefore, although System.Int32[] is an array of values ​​in C #, Integer[] is an array of references to Integer objects and, as such, is not suitable for higher performance calculations.

+4
Jan 06
source share

The built-in date / calendar function in Java is terrible compared to System.DateTime. Here is a lot of information about this: What happened to the Java Date and Time API?

Some of them can be fixed for the C # developer:

  • The Java Date class has been modified, which could result in date return and transfer dates being dangerous.
  • Most java.util.Date constructors are deprecated. Just instantiating the date is pretty verbose.
  • I never got a java.util.Date class to interact well with web services. In most cases, dates on both sides wildly transformed into other dates and times.



In addition, Java does not have all the same functions as the GAC and the strongly named assemblies. Jar Hell is a term that may be mistaken when linking / referencing external libraries.

Regarding packaging / deployment:

  • it can be difficult to pack web applications in EAR / WAR format, which are actually installed and run on multiple application servers (Glassfish, Websphere, etc.).
  • Deploying your Java application as a Windows service requires much more effort than in C #. Most of the recommendations I received for this included a proprietary third-party library. Application configuration
  • is not as simple as including the app.config file in your project. There is a java.util.Properties class, but it is not so reliable, and finding the right place to delete your .properties file can be confusing.
+2
Jan 6 '10 at 20:10
source share

There are no delegates in Java. Therefore, in addition to all the benefits that delegates bring to the table, events also work in different ways. Instead of just attaching a method, you need to implement an interface and attach it.

+1
Jan 06 '10 at 17:16
source share

One thing that jumps out of b / c on my interview list is that in Java there is no β€œnew” analogue of keywords to hide the method, and therefore there is no compiler warning β€œyou should put new here”. The random method hiding when you wanted to override leads to errors.

(for example, edit) Example: B comes from A (using C # syntax, Java behaves the same as the last, I checked, but did not give a warning about the compiler). Is foo or B foo called? (A gets the call, probably surprising the developer who implemented B).

 class A { public void foo() {code} } class B:A { public void foo() {code} } void SomeMethod() { A a = new B(); // variable type is declared as A, but assigned to an object of B. a.foo(); } 
+1
Jan 06 '10 at 17:18
source share

Java does not have LINQ, and the documentation is hell. Java user interfaces are a pain to develop, you lose all the good things Microsoft has given us (WPF, WCF, etc.), but you got hard-to-reach, barely documented "APIs".

+1
Jul 09 2018-10-09T00:
source share

The only problem that I have encountered so far when working with Java coming from C # is exceptions and errors.

For example, you cannot catch an error from memory using catch (Exception e).

See below for more details:

why-is-java-lang-outofmemoryerror-java-heap-space-not-caught

0
Jan 06 '10 at 17:53
source share

It was as long ago as I was in Java, but the things that I immediately noticed from the point of view of application development are the C # event model, drag and drop using C #, and using layout managers in Swing (if you do App dev) and handling exceptions with Java, making sure you catch the exception, and C # is not required.

0
Jan 06 '10 at 19:49
source share

The most annoying difference for me when I switch to java is a line declaration.

in C # string (most of the time) in Java string

It's pretty simple, but believe me, it makes you lose so much time when you have the habit of s not s !

0
Jan 6 '10 at 20:40
source share

In response to your very direct question in your title:

"C # developers learning Java, what are the biggest differences you can ignore?"

A: the fact that Java is much slower on Windows.

0
Aug 18 '10 at 4:08
source share



All Articles