Default access does not render the private access modifier redundant.
Language designers position on that is reflected in official tutorial - Controlling Access to Members of a Class and it's pretty clear (for your convenience, relevant statement in the quote made bold):
###Tips on Choosing an Access Level:
If other programmers use your class, you want to ensure that errors from misuse cannot happen. Access levels can help you do this.
- Use the most restrictive access level that makes sense for a particular member. Use private unless you have a good reason not to.
- Avoid public fields except for constants. (Many of the examples in the tutorial use public fields. This may help to illustrate some points concisely, but is not recommended for production code.) Public fields tend to link you to a particular implementation and limit your flexibility in changing your code.
Your appeal to testability as justification for completely dropping private modifier is wrong, as evidenced eg by the answers in http://programmers.stackexchange.com/questions/135047/new-to-tdd-should-i-avoid-private-methods-now
Of course you can have private methods, and of course you can test them.
Either there is some way to get the private method to run, in which case you can test it that way, or there is no way to get the private to run, in which case: why the heck are you trying to test it, just delete the damn thing...
Position of language designers on the purpose and usage of package level access is explained in another official tutorial, Creating and Using Packages and it has nothing in common with the idea of dropping private modifiers (for your convenience, relevant statement in the quote made bold):
You should bundle these classes and the interface in a package for several reasons, including the following:
- You and other programmers can easily determine that these types are related...
- You can allow types within the package to have unrestricted access to one another yet still restrict access for types outside the package...