When I think of Java I tend to think in packages, not "modules", but I guess I'm too back-end/API oriented. Modules are front-end/use-case oriented and should be mostly in the view/controles layer.
In the business logic/model layer you should not worry about "module" size, since classes, interfaces etc, would be in packages.
In the presentation/view-controller you can think of "module" size, but then it's not clear what can be considered "large". For me, large is about lines of code, not number of classes. What worry me is the size of classes, not the number of them.
The size of a module is mainly dictated by the use-cases and the features the application will have. Do you feel a given screen is doing too much ?
In conclusion, if you are doing object oriented design well, you should not worry about number of class. Worry about classes having too many lines of code or screens/applications doing too much.
EDIT: I'm really meaning encapsulation of larger ideas than a single class, and re-use of code across multiple projects.
An example package could be a Swing dialog box which has one main public class that client-code should use and any number of implementation classes which client code should not see. Java makes this difficult (until Jigsaw). Should this package be a module (own jar) if its shared over projects, or should they all be bundled up into a large "shared-dialogs" project?
