It is possible to do (messily) in some cases; e.g. if your application's classes are loaded from local directories or JAR files. Basically, you need to map the package name to a pathname and use the File and/or ZipFile APIs to look for files in the relevant "directory" whose name ends with ".class". Then you use Class.forName()
load the corresponding classes (trying to avoid initializing them), and use clazz.isAssignableFrom(subclazz)
to see which of them are subclasses.
But this won't work in all cases. One problem is that the ClassLoader API does not support iterating over all of the classes / packages that it could load.
I would recommend that you find an alternative approach to the problem you are tying to address.
EDIT - in response to this comment.
It seems this is a massive fault in the java reflection API
I understand that the omission is deliberate. If the classloader API did include a method to give all classes in a package, it would limit the schemes that can be used for classloading. For example, URLClassLoader would not be implementable for 'http:' URLs because the HTTP protocol does not provide a standard way to retrieve the entries in a directory.
Besides, there are few situations where a production application really needs to reflectively find all classes in a package.