I only want specific classes of a package to be public and act as the facade.Why do you care if others have visibility to the interface to these methods? I've never had much of a problem discerning what methods constitute the correct interface for a class. Just because some methods are declared public does not guarantee that they will be called in the correct circumstances (and many times may require a correct sequence).
On the one hand, you can solve this fairly trivially in Smalltalk by (a) naming the private methods in such a manner that it's obvious that they are not part of the intended public interface; and (b) creating groups of methods (messages) such that one group is called private - the facility for grouping methods into groups doesn't seem to be part of the Java culture.
On the other hand, you can make the argument that simply having 4 levels of visibility is insufficient for a project of any complexity. What may be required to be public at one layer of the software, may really be totally irrelevent to the a higher level of abstraction. Ok, so Java recognizes this be having a package level visibility, but that just ups the level to one additional layer. What about interaction and layering at the package level. At some point, it becomes obvious that the decision to expose an interface at some level of publicity becomes a design decision pitting openness and flexibility of the classes against weighing down the system with arbitrary levels of closed class interfaces.
Eiffel tries to solve this problem by allowing the granting of rights to methods to be controlled on the micro level down to which classes may access which methods. Modula-3 had a more sensible approach by allowing you to define different instances of interfaces to a class, thus allowing you to publish a spec for varying levels of abstractness to the class.
I want mistakes such as passing a string parameter instead of an integer to be trapped at compile-time, not at system testing.And what if you are passing parameters to-and-fro in a much more loosely coupled framework - let's say something like DHTML, where the requests are filtered through web pages? When you're passing objects in and out of collections, that static type checking seemingly causes about as many errors as it solves - and collections (along with message passing) is what Object Oriented Programming should be about.
I'm in the midst of a little C# ditty and I can say that it drives me crazy to have casting in practically 10% of the assignments - and C# with it's boxing/unboxing requires less casts than Java. What does that mean. It means that the code is not flexible in that the types get hard-coded a bunch of lines of code (change the types involved and you got a whole lot of touching to do). It also means that the comiple time type checking is useless as you are passing the check on to run time (hey compiler forget that I'm assigning an Object to a String - tell me a runtime if that's what actually happens).