In C# you can mark a class as internal
so that it is开发者_开发技巧 only accessible from within the same package. Is there anything similar in Java?
You can create package-private classes by omitting the security modifier (public, private) from the class's declaration.
package com.sample;
class MyPackagePrivateClass
{
...
}
Dropping the access modifier is similar to internal in C#.
C#
public class A
{
public static int X;
internal static int Y;
private static int Z;
}
internal class B
{
public static int X;
internal static int Y;
private static int Z;
public class C
{
public static int X;
internal static int Y;
private static int Z;
}
private class D
{
public static int X;
internal static int Y;
private static int Z;
}
}
Java
public class A
{
public static int X;
static int Y;
private static int Z;
}
class B
{
public static int X;
static int Y;
private static int Z;
public class C
{
public static int X;
static int Y;
private static int Z;
}
private class D
{
public static int X;
static int Y;
private static int Z;
}
}
Source: http://www.javacamp.org/javavscsharp/internal.html
this Question has an accepted answer before but I think the answer is not fully clear for some one who is new in java coming from .Net.
Does java have some exact equivalent for internal modifier in C# ? short answer is NO (but you can achieve it some how and i will tell)!!
internal in C# is actually an "assembly-private" modifier. what is an assembly ?
Assembly is any product of your project (DLL or EXE in C# - equivalent in java can be a JAR file)
there is not any exact equivalent for internal in java. and what has been answered by Bryan Kyle and accepted is actually "package-private" (packages in java are equivalent for namespaces in C#) but some how what has been answered is the closest way to get the same result.
BUT how to get a fully same result as internal ? cant java have a solution for this ? the answer is YES.
it does have. but not with a modifier. actually the best way to do this is a secret in packaging. the best practice of packing is to pack your classes by their relation not by their type.
many of us use packages named "Models" or "Presenters" and put all our models or presenters in them. while this is wrong. packages should be like "Book" containing "BookModel.java", "BookPresenter.java" , .....
this way you can make them package-private by omitting the modifier and have not any problem because you can access them in any class which need your package-private class because you have a good practice of packaging.
Yes. It's called package private, you just define the class without any modifiers:
package com.blah;
class Foo{ }
I'm not familiar with C#, but in Java the default protection is that something is only accessible within the package:
public=accessible by anyone
private=accessible only within the current class
protected=accessible within the package or in any class that inherits from the current class
default=accessible within the package
I've always thought there should be a way to say "accessible by any class that inherits from the current class but not from anywhere else, this package or any other". But there isn't.
Most of the answers (including the accepted one) talk about package-private. But that is far from the internal
in C#.
A use case where you want only your classes in the same source root to access another class in the same source root and possibly at different packages (still in the same source root) while keeping it package-private is simply impossible in Java. If you use package-private then only the classes in the same package will have access to that resource. However, even the classes one level down in the same package (i.e. another package under that package) cannot access that class.
a.b.c.A --> class A
a.b.c.d.B --> public class B
Here B
cannot access A
. This forces you to unfortunately mark A
as public.
The main difference is in the way C# or Java packs the compiled code. C# can mark them as internal (i.e. do not export the symbol from the assembly) but Java packs as jar
files and the way a jar is imported is completely different.
So what is the practical solution: Well first of all there is no forcing solution. One can use javadocs or annotations to mark a class as internal and discourage people from using it, stating that it is internal and it can be changed a lot, it is not part of the public API, just don't use it or you might get into trouble if you migrate to a new release...
I see two ways of doing this:
name your package as internal:
package org.mycoollib.api; /** This class is part of my public API*/ public class A{ //... } package org.mycoollib.internal; /** This an internal class, don't use it or your code might not work in a new release */ public class B{ //... }
Some real life examples: jdk.internal
, io.netty.util.internal
and so on. When I see internal
as a package name I simply avoid using the classes in that.
Use annotations to achieve the same goal as in
1
package org.mycoollib.api; /** This class is part of my public API*/ public class A{ //... } package org.mycoollib.internal; /** This an internal class, don't use it or your code might not work in a new release */ @Internal public class B{ //... }
Example: android.annotation.SystemApi, org.apache.poi.Internal
There might even be libraries out there to provide such kind of annotations as well as maven plugins to warn people during their builds.
As a result, the solution is in the way of thinking: We simply warn people not to use it because we don't guarantee that its name and methods won't change. If they still insist on using it, then so be it. They know the risk.
You can make a class package local. This is the default scope for a class. i.e. where you have no access modifiers.
If you really want to put sometime you can create an annotation e.g. @package_local, I do this in places where I speicifc want it to be package local and didn't just leave it unspecificed.
Yes, the default (package private) access level. Just leave out any access modifier on your class definition and you get what you want.
精彩评论