What else apart from these should a Java developer learning C# keep in mind?

[Monica Shiralkar]

I have been a java developer who has now started learning C#. Below are some of my learning in C# :



C# is not platform independent like Java and can only work on Windows.
In C# instead of creating Jar like java we create a dll.
In C# we use the inbuilt IIS server of OS instead of tomcat/JBoss etc.
C# has method names in Pascal case unlike camel case in Java.


What else apart from these should a Java developer learning C# keep in mind?

[Bill Crim]

Platform	.NET Framework	Mono(Framework Clone)	.NET Core
Windows	Yes. Some versions are OS components	Yes	Yes
Mac	No	Yes	Yes
Linux	No	Yes	Yes

C# is platform independent. Microsoft makes .NET Framework on windows, Mono is the .NET Framework on Mac, Linux, and mobile. If you use .NET Core(This is preferred moving forward), it is cross platform. They removed concepts that were Windows centric and moved them into their own packages. .NET Framework is a shared component installed at the machine level. .NET Core does not use shared libraries. So you are deploying exactly the runtime you compiled it on. .NET Core is driven entirely by the package management system to bring in runtime components.


In Java, each class is compiled to a separate file, which are then gathered into a JAR. In .NET a Project is compiled into a DLL. You can then bundle 1 or more dlls into a NuGet package(NuGet is the packaged manager for .NET) which will also manage dependencies. So a Maven package is analogous to a NuGet package. A Project compiling to a DLL is equivalent to a Jar for a single library. But a jar is a more flexible unit of deploy since you can include any arbitrary java code in it.

In the Windows space, IIS is the web server. IIS, supporting .NET framework, is setup as AppPool(the executable) and AppDomain(the isolation container).
If you are running .NET Core, on any platform, it is just a binary module. You can plug it into IIS or Apache like you would any other mobile.



Something else to keep in mind, on C# they have Properties as the method of implementing getters and setters.

public String getName()
{
    return name;
}
public String setName(String value)
{
    name = value;
}

If you have a simple getter/setter, it will also support access restrictions.

public string Name{ get; set; } //Simple property, with automatically created backing variable.
public DateTime BirthDate {get; private set; } //

This automatically creates private backing variable. The "Property" construct is an outgrowth of a legacy of COM. It would understand that a function called "get_Name()" and "set_Name" were related. So properties are just functions under the hood, and you can create custom backing code if you want.

private string name;
public Name
{
    get 
    { 
       return name; 
    }
    set
    {
        if( value == null ) throw new ArgumentNullException();
        name = value;
    }
}

Many things in C# are done with Delegates where Java would use objects. Delegates are a top-level language feature. Events, Lambdas, LINQ are just forms of delegates. You start threads and use Tasks(Promises) using delegates. Think of a delegate as a type-safe function pointer. If you want to do composition it is generally preferred to use generics and delegates instead of a bunch of objects.

[Claude Moore]

Bill's very good explanation apart, let me suggest something I learnt at my expense: C#'s syntax is really similar to Java's, but under the hood they are really two different beasts, and such  similarity could be deceiving.
Years ago I approached C# for the first time wrongly believing that, more or less, understanding deeply C# would be easy, given the pretty similar language syntax. I was wrong. Syntax is similar, underlying semantic is really different.

[Monica Shiralkar]

Thanks. This information is useful to someone who is beginning to learn C# after doing Java for many years.

[Monica Shiralkar]

Another difference which I have seen is that C# does not have concept of checkered exception and for the same reason does not have throws keyword.

[Bill Crim]

Monica Shiralkar wrote:C# does not have concept of checkered exception

I laughed at "checkered exception". I have often been frustrated with checked exceptions in Java, and I have to say your description is better.

[Monica Shiralkar]

Sorry for that typo. Another differences which I want to add are. C# has internal modifier for class which is not there in Java. C# has out parameter which is not there in Java. C# has Using statement which is not there in Java.  

[Campbell Ritchie]

Monica Shiralkar wrote:. . . . C# has out parameter which is not there in Java.

Does that mean it supports pass by reference?

C# has Using statement which is not there in Java.  

Isn't that the equivalent of import...?

[Monica Shiralkar]

I am taking about the Using statement not the Using keyword. E. G  Using the Using statement removes the need for closing the sql connection in a finally block.

[Stephan van Hulst]

Campbell Ritchie wrote:Does that mean it supports pass by reference?

Yes. You can use the 'ref' keyword to use normal pass-by-reference, or the 'out' keyword to indicate that the method must treat the parameter as uninitialized, and assign it a definite value before it returns.

Monica Shiralkar wrote:C# has Using statement which is not there in Java.

Incorrect. Since Java 7 there is try-with-resources, which pretty much does the same thing as using in C#.

C#

using (var stream = File.OpenRead(path))
{
  //
}

Java

try (var stream = Files.newInputStream(path)) {
  //
}

[Monica Shiralkar]

Thanks for correction.

[Monica Shiralkar]

In C# we can have method inside method. This is not there in Java.

[Stephan van Hulst]

In Java on the other hand you can write method local types and anonymous classes. And both languages allow you to assign a lambda expression to a variable of a functional interface (Java) or a delegate type (C#).

[Monica Shiralkar]

After using C# since some months and worked for years on Java, I felt that the most significant feature in C# which does not have equivalent in Java is LINQ. Other things are present in different ways on both languages but LINQ is only in C#.  

[Stephan van Hulst]

How do you figure? Pretty much anything you can do with LINQ you can do with streams in Java.

I think a much bigger and more interesting feature in C# is that you can use LINQ to build expression trees that are compiled at runtime against the system you want to run them on. For instance, I can write SQL queries in LINQ, which are compiled and executed on the database end, rather than in the application server.

[Monica Shiralkar]

Thanks. Apart from the difference you said I think Streams are tied to Lambda expression (to make use of streams you need to use lambda expressions) but for using LINQ you may or may not use lambda expressions.

[Stephan van Hulst]

You keep using the phrase "lambda expression" in places where it's not the only applicable concept. I can write Stream operations without using a single lambda expression. Are you using lambda expression as a catch all phrase for "functions"? Why?

If by "LINQ expressions without using lambda expressions" you mean "query syntax", then that really isn't such an interesting difference. Query syntax in C# is really just syntactic sugar for "method syntax", something that Java supports on streams as well.

As I said in my previous post, much MUCH more interesting is that LINQ expressions in C# can yield expression trees rather than function objects. An expression tree is really a "piece of code" that you can treat as an object. You can even modify it, and perform operations such as "insert a statement between these two lines of code" or "change the return type of this piece of code", or as I already alluded to "compile and run this piece of code on this remote system". Frameworks like Entity Framework or Moq make excellent use of this capability.

[Stephan van Hulst]

Features in C# I gratefully make use of and wish were available in Java are pattern matching and inline variable declaration:

Pattern matching:

if (objectOfBaseType is DerivedType objectOfDerivedType) {
  // do something with derived type
}

Inline variable declaration:

if (!dictionary.TryGetValue(key, out var value))
  return false;

// do something with value

Other really cool features are anonymous types and tuple-like deconstruction:

Anonymous types:

var namesByCity = people

  .Select(person => new {
    name = person.FullName,
    city = person.Address.City,
  })

  .GroupBy(nameAndCity => nameAndCity.city);

(Or in query syntax:)

var namesAndCities =
  from person in people
  select new {
    name = person.FullName,
    city = person.Address.City,
  };

var namesByCity =
  from nameAndCity in namesAndCities
  group nameAndCity by nameAndCity.city;

Tuple deconstruction:

var (familyName, givenName) = person.Name;

[Stephan van Hulst]

Finally, I think the most important difference between the two languages for me is that in C# generic type information is available at runtime. That means I can do stuff like this:

var person = DeserializeAs<Person>(xml);

[Monica Shiralkar]

Thanks. I will read more about Java Streams and clear that.

[Monica Shiralkar]

Something which a Java developer has to most commonly keep in mind while working on C# with respect to  the coding standards, is that the methods (which we so commonly create)  are not camelCase like Java but are PascalCase. I used to do this mistake and correct it because of the Java habbit.

[Monica Shiralkar]

Found that IEnumerable is the C# equivalent of Java 8 Streams.

In C# ,we can directly assign a List to the type IEnumerable as below:

List<string> myIEnumerable =myList;

Whereas in Java, we cannot just simply assign myList to the type Streams.We need to instead do as below:

List<String> myStream=myList.stream();

[Stephan van Hulst]

Be careful though: Like Java streams, C# enumerables may be read-once. If you iterate over an IEnumerable twice, it may throw an exception.

Java makes the difference between an in-memory collection and a lazy sequence explicit. With C# it's easier to fall into this trap.

[Monica Shiralkar]

Came across more:

In C# private fields have convention to start name with underscore. C# POCO field has naming convention to use Pascal Case.Java mostly has similar naming convention across all except for the case of constants .

In C#, for both implementing an interface as well as extending a class ,the same colon symbol is used.

[Stephan van Hulst]

Monica Shiralkar wrote:In C# private fields have convention to start name with underscore.

Wrong. Where did you get this?

C# POCO field has naming convention to use Pascal Case.

Wrong. Fields start with a lowercase letter.

Java mostly has similar naming convention across all except for the case of constants.

Wrong. It's convention to start method names with an uppercase letter in C#, whereas in Java you start them with a lowercase letter.

[Monica Shiralkar]

Wrong. It's convention to start method names with an uppercase letter in C#, whereas in Java you start them with a lowercase letter.

Sorry.I did not mean this .I meant in Java we dont have concept of having different naming conventions for variables unless we talk about constant variables (in Java if variables use camel case then even in a pojo variables will start with camel case and the same will be there for a  private field ).  In C# there are different conventions for variables at different places .

[Tim Holloway]

Stephan van Hulst wrote:

Monica Shiralkar wrote:In C# private fields have convention to start name with underscore.

Wrong. Where did you get this?

C# POCO field has naming convention to use Pascal Case.

Wrong. Fields start with a lowercase letter.

Java mostly has similar naming convention across all except for the case of constants.

Wrong. It's convention to start method names with an uppercase letter in C#, whereas in Java you start them with a lowercase letter.

Underscores as a beginning character for "private" entities predate C#. The C++ translator used them extensively for internal names to avoid conflicts with source code names. I used that convention myself when I ported C++ from Unix to the Amiga, in fact. Function names beginning with underscores have been widely used, for example where macros front standard library functions. As an example, "_printf" was used in the Lattice C compiler to be a smarter version of printf while reserving the "real" printf for cases where full language compatibility. The _printf was mapped in stdio.h to printf. The primary difference being that "real" printf would be obligated to drag in the floating-point libraries even if they were not needed in the program, since the format string was ordinarily interpreted at runtime.

Seriously secret stuff started with double-underscores.

I've never heard that it was good practice to start method names with upper case in C#. Certainly it's something I've never seen in C++ as routine. The main difference between the OOP C dialects and Java is that Java prefers camelCase, and C prefers names_with_underscores. But I've been hopelessly corrupted myself and have ended up being pretty random. A lot of the C# libraries are mappings onto Windows non-OOP methods, however. In fact, that's how Microsoft got sued over J++.

I'm not sure I'd used Pascal as a reference. Pascal, if I recall, was case-insensitive with respect to naming.

Incidentally, one very significant difference in C++ these days is namespaces. I don't recall if C# supports them, though.

[Monica Shiralkar]

Stephan van Hulst wrote:
Wrong. Fields start with a lowercase letter.

For instance the below poco has fields with Pascal Case:

[link]

https://www.google.com/imgres?imgurl=https://aspblogs.blob.core.windows.net/media/scottgu/Media/image_thumb_30B768DA.png&imgrefurl=https://weblogs.asp.net/scottgu/code-first-development-with-entity-framework-4&docid=YlW74tyqtCCwPM&tbnid=ZH2b4r4FqrDqKM:&vet=1&w=509&h=513&itg=1&hl=en-IN&source=sh/x/im

[\link]

[Stephan van Hulst]

Tim Holloway wrote:I've never heard that it was good practice to start method names with upper case in C#.

Well, pretty much all of the .NET standard API uses upper case for method names and I'm also quite sure it's what Microsoft prescribes in its style guide. It's also what most of the C# community uses so I think it's fair to say it's convention.

I'm not sure I'd used Pascal as a reference. Pascal, if I recall, was case-insensitive with respect to naming.

Microsoft just named it that way because Anders Hejlsberg, the creator of Turbo Pascal, is a lead architect of the C# language. It doesn't have anything to do with the Pascal language itself.

[Stephan van Hulst]

Monica Shiralkar wrote:For instance the below poco has fields with Pascal Case

Those are not fields. They are properties. Properties are closer to methods than they are to fields.

[Monica Shiralkar]

Stephan van Hulst wrote:

Monica Shiralkar wrote:In C# private fields have convention to start name with underscore.

Wrong. Where did you get this?

I had seen it at many places like this
[Link]
https://www.google.com/search?q=C%23+private+variables+_&rlz=1C1CHBD_enIN880IN880&hl=en&tbm=isch&source=lnms&sa=X&ved=0ahUKEwiTvKStoeDpAhXZzTgGHVDGDg8Q_AUIECgD&biw=1536&bih=754&dpr=1.25#imgrc=cL1WfrXJ3BhOEM

[/Link]

[Stephan van Hulst]

Just because you found some people doing it in a Google search doesn't make it convention.

The Microsoft Naming Guidelines are the closest thing you'll get to convention. The latest version doesn't specify any guidelines for private fields, but older versions explicitly discourage the use of underscores for instance fields.

[Monica Shiralkar]

I will follow the Microsoft guidelines. Wondering why so many people are following this wrong underscore convention .

Thanks

[Stephan van Hulst]

It's not wrong. It's just not generally accepted convention.

Tim already gave you some historical background on why underscores were used.

[Monica Shiralkar]

Not exactly about  C# and Java but more about Visual Studio and eclipse :

In eclipse in the autosuggestion if I get toString ,just selecting it automatically adds the braces to make it toString()

In visual studio, when I do that it adds ToString and I still have to manually add the braces to make it ToString()

In eclipse ,if I try to use a variable without initialising it ,it gives the suggestion to automatically initialise it  (for e.g to null).

In visual studio it will give the message for not initialized but not give suggestion to automatically initialise .I have to manually initialise for e.g to null.


For someone using Eclipse ,these things may be mildly frustrating .

[Tim Holloway]

Eclipse features auto-completion - a service that tries to avoid making you type things that it already knows should be typed in, thus speeding your coding and trying to reduce the number of possible bugs in the program.

The last time I used Visual Studio, Eclipse hadn't been invented yet. In fact, I'm not sure if Java had been invented yet. It was a nice enough program, but a Raspberry Pi has more computing power than the desktop systems I was developing on back then. Things like auto-complete add to the RAM and CPU requirements of the IDE program. Plus, of course, there were plenty of other problems that hadn't been solved back then.

As I understand it, Visual Studio these days comes in 2 or 3 different flavors, one of which is free and I've heard good things overall about them, but as I said, I've never worked with any of them. It's possible that there's auto-complete in the version that you're using and it's not turned on. Or perhaps Microsoft hasn't seen fit to implement auto-complete.

Regardless, that sort of stuff is for convenience of coding, so it shouldn't have any bearing on what you code, only on how you type it in.

[Stephan van Hulst]

Honestly Monica, comparing different IDEs to each other feature by feature is a rabbit hole that you'll never manage to climb out of, especially IDEs that are so different as Visual Studio and Eclipse. There is just no point.

[Monica Shiralkar]

Stephan van Hulst wrote:Just because you found some people doing it in a Google search doesn't make it convention.

The Microsoft Naming Guidelines are the closest thing you'll get to convention. The latest version doesn't specify any guidelines for private fields, but older versions explicitly discourage the use of underscores for instance fields.

I was going through a pluralsight training and it was surprising that even they used underscore convention for private fields. Don't know half the world is ignoring the Microsoft guideline on this .

[Campbell Ritchie]

That sounds like Hungarian notation; see Joel Spolsky.