The importance of rigid definitions – or why a verbose explanation is sometimes a good idea.

So I have been wiping the cobwebs from my Java skills and kicking myself for neglecting them. I suppose with work being focused on .NET development, two young children and a training schedule that leaves very little time for exploration on personal projects, it was bound to happen.

 

Anyway, things have changed now and I am able to squeeze in personal development time by sleeping less . Right, lets get to the point of this article. While designing an API in Java I noticed that I was finding it very difficult to package my classes the way I was doing it in .NET so I started doing some digging.

 

My first thought was to have a look at the access modifiers available in both languages. Do a like for like comparison and see if there were any equivalents. So the C# language has the following access modifiers:

 

C#

• Public: This is pretty much a free for all. The class can be accessed by everything inside the assembly and anything referencing the assembly. This applies to types and type members.
• Private: This makes members of the class only accessible to operations in the definition of the class. Kinda like private parts
• Internal: This allows the the types or type members to be visible from the within the same assembly. So even if a different assembly shares the namespace (for whatever reason) it will not be able to access the internal types or methods of the referenced assembly.
• Protected: This is a member access modifier that dictates that only types that extend the declaring type can access this member. So a shared property, field, method or function that you want to be visible inside a type extending the type declaring the members but not available internally to the assembly or publically.

 

Right lets move on shall we?

 

Java

• Public: Pretty much the same as C#. Free for all on everything declared.
• Private: Again, pretty much the same as C# and the private parts.
• No Access Modifier: This means that anything declared in the type or the type itself will only be visible in the package space it is declared in. Remember this! It is the topic of this post.
• Protected: Available to types extending the declaring type.

 

Right lets get to the point of this article. Now that we have established each languages modifiers, lets have a look at this http://www.javacamp.org/javavscsharp/internal.html

 

Looking at that you will see that the C# access modifier “internal” is implied to be the equivalent of the Java default or no access modifier declaration. Does the Java definition behave the same as the C# internal definition? Well have a look at the definitions again:

• C# Internal: Accessible to everything inside the assembly. This means namespaces moving up to the root namespace and down to the last namespace node.
• Java No Modifier: Only available inside the package it is declared in.

 

Can you see it yet?

 

Lets have a look at a code sample real quick:

C# Code sample

//Assuming this is inside assembly my.cool.dll
namespace my.cool.project{
  internal class Cheese(){}
}

namespace my.cool{
    public class StartTheCheese(){
        var cheese = new Cheese(); //valid
    }
}

namespace my.cool.project.goes.on{
    public class DigestTheCheese(){
        var cheese = new Cheese(); //valid
    }
}
//end assembly

//Assuming this is inside assembly my.ref.dll
namespace my.cool{
    public class DoWeHaveCheese(){
        var cheese = new Cheese(); //invalid
    }
}

Java Code Sample

package my.cool.project

class CatchMe(){ // note that no access modifier is declared
 //body
}

package my.cool

public class TheCheese(){
    CatchMe catchMe = new CatchMe(); //fails!   
}

You can see it now right? The primary, intrinsic difference is that the C# internal modifier can span multiple namespaces in the same assembly. The Java declaration with no access modifier cannot be seen outside the package my.cool.project. This means that there is no equivalent “internal” in Java. So here is the crux of the matter. If making comparisons, like in maths, we have to find the lowest common denominator before comparing or performing operations of logic in deciding the equivalents. Compare apples with apples to avoid confusion. Things we might take for granted will drive other people mad!

 

References:

• http://msdn.microsoft.com/en-us/library/6tcf2h8w%28v=vs.71%29.aspx



• http://www.javacamp.org/javaI/Modifier.html



• http://www.javacamp.org/javavscsharp/internal.html