Dealing With Java Default Level Access Specifiers

I've seen some code in a project recently where some fields in a couple classes have been using the default access modifier without good reason to. It almost looks like a case of "oops, forgot to make these private". Since the classes are used almost exclusively outside of the package they are defined in, the fields are not visible from the calling code, and are treated as private. So the mistake/oversight would not be very noticeable.

However, encapsulation is broken. If I wanted to add a new class to the existing package, I could then mess with internal data in objects using fields with default access.

So, my questions:

1. Are there any best practices concerning default access specifiers that I should be aware of? Anything that would help prevent this type of accident from re-occurring?
2. Are are any annotations which might say something to the effect of "I really meant for these to b开发者_如何学Pythone default access"?
3. Using CheckStyle, or any other Eclipse plugins, is there any way to flag instances of default fields, or disallow any not accompanied by, say, a "//default access" comment trailing them?

---

In terms of style, I have seen some style guides which recommend putting "package" in a comment to denote that it was intentional. Like this:

/*package*/ int myInt;

It's unfortunate that the Java language spec doesn't allow use of "package" explicitly; after all, it's already a reserved keyword!

---

I would suggest running the UCDetector on the code base. From the main page:

UCDetector creates markers for the following problems, which appear in the eclipse problem view:

• Unnecessary (dead) code
• Code where the visibility could be changed to protected, default or private
• Methods of fields, which can be final

---

By convention, you should not define your class in his package. The author is reasonable to make that assumption, and he should be the only one who accesses these package variables.

If you choose to break that convention, you are allowed to, and you should know what you are doing. You know what else you can do to mess around with the design, since you have the source? Everything!

The access level is an honor system after all. It is there to help you, but it's not your dictator.

JDK classes use package level variables extensively. And it's my favorite too. public and protected have important roles for public APIs, private when you are really paranoid and you don't even trust yourself. For everything else - default/package level, which allows an author to freely access, but difficult for users to access.

"How can an author be so arrogant and think that he doesn't have to mark his private variables as private? He is doing his job wrong!" - well, who are you and how is that your business?

Obviously Java creators thought that is should be the most frequently used leve, therefore we should save some key taps, and don't impose a keyword on it.