Best way to really grok Java for a C# guy

Question

I've recently started developing applications for the Blackberry. Consequently, I've had to jump to Java and learn that and its associated tools. The syntax is easy, but I keep having issues with various gotchas and the environment.

For instance, something that surprised me and wasted a lot of time is absence of real properties on a class object (something I assumed all OOP languages had). There are many gotchas. I've been to various places where they compare Java syntax vs C#, but there don't seem to be any sites that tell of things to look out for when moving to Java.

The environment is a whole other issue all together. The Blackberry IDE is simply horrible. The look reminds me Borland C++ for Windows 3.1 - it's that outdated. Some of the other issues included spotty intellisense, weak debugging, etc... Blackberry does have a beta of the Eclipse plugin, but without debugging support, it's just an editor with fancy refactoring tools.

So, any advice on how to blend in to Java?

Answer 1

The short answer is - it's going to be annoying, but not difficult.

Java and C# have all the same underlying concepts, and a lot of the libraries are very close in style, but you're going to keep bumping your head across various differences.

If you're talking about class properties, Java has those. The syntax is

public class MyClass {
    public static int MY_CLASS_PROPERTY = 12;
}

I would seriously suggest you get a better IDE. Any of Netbeans, Eclipse, IDEA, JBuider is going to make your transition a lot more pleasant.

Answer 2

This guy here had to make the inverse transition. So he listed the top 10 differences of Java and C#. I'll take his topics and show how it is made in Java:

Gotcha #10 - Give me my standard output!

To print to the standard output in Java:

System.out.println("Hello");

Gotcha #9 - Namespaces == Freedom

In Java you don't have the freedom of namespaces. The folder structure of your class must match the package name. For example, a class in the package org.test must be in the folder org/test

Gotcha #8 - What happened to super?

In Java to refer to the superclass you use the reserved word super instead of base

Gotcha #7 - Chaining constructors to a base constructor

You don't have this in Java. You have to call the constructor by yourself

Gotcha #6 - Dagnabit, how do I subclass an existing class?

To subclass a class in Java do this:

public class A extends B {
}

That means class A is a subclass of class B. In C# would be "class A : B"

Gotcha #5 - Why don’t constants remain constant?

To define a constant in Java use the keyword final instead of const

Gotcha #4 - Where is ArrayList, Vector or Hashtable?

The most used data structures in java are HashSet, ArrayList and HashMap. They implement Set, List and Map. Of course, there is a bunch more. Take a look at http://java.sun.com/docs/books/tutorial/collections/index.html

Gotcha #3 - Of Accessors and Mutators (Getters and Setters)

You don't have the properties facility in Java. You have to declare the gets and sets methods for yourself. Of course, most IDEs can do that automatically.

Gotcha #2 - I can’t override!?

You don't have to declare a method virtual in Java. All methods - except those declared final - can be overridden in Java.

And the #1 gotcha…

In Java the primitive types int, float, double, char and long are not Objects like in C#. All of them have a respective object representation, like Integer, Float, Double, etc.

That's it. Don't forget to see the original link: http://crfdesign.net/programming/top-10-differences-between-java-and-c

There's a more detailed discussion.

Answer 3

Java is not significantly different from C#. On a purely syntactic level, here are some pointers that may get you through the day:

1. In Java you have two families of exceptions: java.lang.Exception and everything that derives from it, and RuntimeException. This is meaningful because in Java exceptions are checked; this means that in order to throw any non-runtime exception you also need to add a throws expression to your method declaration. Consequently, any method using yours will have to catch that exception or declare that it also throws the same exception. A lot of exceptions you take for granted, such as NullPointerException or IllegalArgumentException, in fact derive from RuntimeException and you therefore don't need to declare them. Checked exceptions are a point of contention between two disciplines, so I'd recommend you try them out for yourself and see if it helps or annoys you. On a personal level, I think checked exceptions improve code factoring and robustness significantly.

2. Although Java has supported autoboxing for quite a while, there are still quite a few differences between the C# and Java implementations that you should be aware of. Whereas in C# you can interchangeably use int as both a value type and reference type, in Java they're literally not the same type: you get the primitive value type int and the library reference type java.lang.Integer. This manifests in two common ways: you can't use the value types as a generic type parameter (so you'll use ArrayList<Integer> instead of ArrayList<int>), and the utility methods (such as parse or toString) are statically implemented in the reference type (so it's not int a; a.toString(); but rather int a; Integer.toString( a );).

3. Java has two distinct types of nested classes, C# only has one. In Java a static class that is not declared with the static modifier is called an inner class, and has implicit access to the enclosing class's instance. This is an important point because, unlike c#, Java has no concept of delegates, and inner classes are very often use to achieve the same result with relatively little syntactic pain.

4. Generics in Java are implemented in a radically different manner than C#; when generics were developed for Java it was decided that the changes will be purely syntactic with no runtime support, in order to retain backwards compatibility with older VMs. With no direct generics support in the runtime, Java implements generics using a technique called type erasure on which you can read here. There are quite a few disadvantages to type erasure over the C# implementation of generics, but the most important point to take from this is that parameterized generic types in Java do not have different runtime types. In other words, after compilation the types ArrayList<Integer> and ArrayList<String> are equivalent. If you work heavily with generics you'll encounter these differences a lot sooner than you'd think.

There are, in my opinion, the three hardest aspects of the language for a C# developer to grok. Other than that there's the development tools and class library.

1. In Java, there is a direct correlation between the package (namespace), class name and file name. Under a common root directory, the classes com.example.SomeClass and org.apache.SomeOtherClass will literally be found in com/example/SomeClass.class and org/apache/SomeOtherClass.class respectively. Be wary of trying to define multiple classes in a single Java file (it's possible for private classes, but not recommended), and stick to this directory structure until you're more comfortable with the development environment.

2. In Java you have the concepts of class-path and class-loader which do not easily map to C# (there are rough equivalents which are not in common use by most .NET developers). Classpath tells the Java VM where libraries and classes are to be found (both yours and the system's shared libraries!), and you can think of class loaders as the context in which your types live. Class loaders are used to load types (class files) from various locations (local disk, internet, resource files, whatnot) but also constrain access to those files. For instance, an application server such as Tomcat will have a class loader for each registered application, or context; this means that a static class in application A will not be the same as a static class in application B, even if they have the same name and even if they share the same codebase. AppDomains provide somewhat similar functionality in .NET.

3. The Java class library is similar to the BCL; a lot of the differences are cosmetic, but it's enough to get you running for the documentation (and/or Google) over and over again. Unfortunately I don't think there's anything to do here -- you'll just build familiarity with the libraries as you go.

Bottom line: the only way to grok Java is to use it. The learning curve isn't steep, but prepare to be surprised and frustrated quite often over the first two or three months of use.

Answer 4

The Blackberry IDE is simply horrible

That's right. I develop in Intellij IDEA, then switch to BB IDE only to run project in emulator. BTW, Intellij IDEA is main reason why I switched from C# to Java. while I still think that C# is better.