Difference Between Namespace in C# and Package in Java

Difference between namespace in C# and package in Java

From: http://www.javacamp.org/javavscsharp/namespace.html

---

Java

Packages are used to organize files or public types to avoid type conflicts. Package constructs can be mapped to a file system.

system.security.cryptography.AsymmetricAlgorithm aa;

may be replaced:

import system.security.Crypography; 
class xxx { ...
AsymmetricAlgorithm aa;

There is no alias for packages. You have to use import statement or fully-qualified name to mention the specific type.

package n1.n2;
    class A {}
    class B {}

or

package n1.n2;
   class A {}

Another source file:

package n1.n2;
   class B {}

Package cannot be nested. One source file can only have one package statement.

C#

Namespaces are used to organize programs, both as an "internal" organization system for a program, and as an "external" organization system.

System.Security.Cryptography.AsymmetricAlgorithm aa;

may be replaced:

using System.Security.Crypography; 
AsymmetricAlgorithm aa;

Alternatively, one could specify an alias for the the namespace, eg

using myAlias = System.Security.Crypography; 

and then refer to the class with

myAlias.AsymmetricAlgorithm 

namespace N1.N2
{
    class A {}
    class B {}
}

or

namespace N1
{
    namespace N2
    {
        class A {}
        class B {}
    }
}

Is namespace in C# is something similar to package in Java

They're similar but not the same. In particular, names are also used for access control in Java (where the default access makes a member available within the same package). That's not the case in .NET - namespaces don't come into accessibility at all in .NET.

Additionally, the way you import types can differ between C# and Java: in Java you can import individual classes, whereas in C# the common using directive imports a whole namespace. On the other hand, C# using directives can also specify aliases, which Java doesn't support.

Both packages and namespaces are ways of grouping related types, so to that extent they're the same... but they differ in the details.

Some comparison between Java package and C# namespace

Does Java allow a single file to contain fragments of multiple packages?

If there is a package statement, it must be the first line of your Java source code. This means that the answer to your question is "no": you can have at most one package declaration per Java source file.

How does a C# programmer must provide the compiler with a complete list of all the files required?

This applies only to building on the command line, because IDEs take care of this automatically. When you build your code on the command line with csc.exe you must provide a list of all files composing your module either by listing them one-by-one, e.g.

csc src\File1.cs src\File2.cs src\File3.cs

or by specifying a pattern:

csc src\*.cs

Java package vs c# assemblies

No they are not same. As also mentioned in the Thread. The best comparison would be with a Java ARchive (Jar) file. Java uses packages to control the namespace, and is very similar to C#'s Namespaces.

Namespaces in C# vs imports in Java and Python

1) Well, you can do the same thing in Java too:

import java.util.*;
import java.io.*;

...

InputStream x = ...;

Does InputStream come from java.util or java.io? Of course, you can choose not to use that feature.

Now, in theory I realise this means when you're looking with a text editor, you can't tell where the types come from in C#... but in practice, I don't find that to be a problem. How often are you actually looking at code and can't use Visual Studio?

2) You can use the same convention in .NET too, of course - and I do, although I don't have empty directories going up the chain... so if I'm creating a project with a default namespace of X.Y, then X.Y.Foo would be in Foo.cs, and X.Y.Z.Bar would be in Z\Bar.cs

That's also what Visual Studio will do by default - if you create a subfolder, it will create new classes using a namespace based on the project default and the folder structure.

Of course, you can also declare types in any old file - but mostly people will follow the normal convention of declaring a type with a corresponding filename. Before generics made delegate declarations rarer, I used to have a Delegates.cs file containing all the delegate declarations for a particular namespace (rather than having a bunch of single-declaration files) but these days that's less of an issue.

How to make the C# namespace work like Java Packages so they rename automatically when moving them?

I fix the problem by using an IDE plugin called Resharper. (Among many, many useful features) it highlights when a namespace is wrong (based on the folder hierarchy and root namespace of the assembly) and can fix it for you.

Note that unlike in Java, there are sometimes very valid reasons for a class to be in a namespace other than the one inferred by the directory structure. A good example might be extension method classes, which need to be in scope in the class that is invoking them. Therefore it is common to have:

/myProject
  /extensions
     /MyExtensionMethodClass.cs

with a namespace like myProject (so that the extension methods can be used anywhere in myProject without a using directive)

Equivalent to java packages in C#

If you create class inside folder, the namespace (which is almost the same as packages in Java) for this class is based on the folder(s) it is inside.

Actually, packages in java are folders too.

Is it a good practice to have a package/namespace and class within with the same name?

I would try to avoid that, since it can make your code harder to read
Eric Lippert has written an article about this, which you can find here:

• part 1,

• part 2,

• part 3

• part 4

I've made the mistake myself a few times, and it certainly made it harder to read some of my code.

C++ Namespaces, comparison to Java packages

In C++ namespaces are just about partitioning the available names. Java packages are about modules. The naming hierarchy is just one aspect of it.

There's nothing wrong, per-se, with deeply nested namespaces in C++, except that they're not normally necessary as there's no module system behind them, and the extra layers just add noise.
It's usually sufficient to have one or two levels of namespace, with the odd extra level for internal details (often just called Details).

There are also extra rules to C++ namespaces that may catch you out if overused - such as argument-dependent-lookup, and the rules around resolving to parent levels. WRT the latter, take:

namespace a{ namespace b{ int x; } }
namespace b{ string x; }
namespace a
{
  b::x = 42;
}

Is this legal? Is it obvious what's happening?
You need to know the precendence of the namespace resolution to answer those questions.

---

Related Topics