Perhaps you've got a normal classloader and you know the path to the file, but you don't know which of the parent directories is the base directory, and which are part of the package structure. You can work out the class name from the file name, but the package is less obvious. One approach would be to work your way up (or down) the directory structure, trying each directory in turn as if it's the base (and the subdirectories, part of the package). Try to load the given class using that info, and if it doesn't work, catch the exception and move on to the next possibility. It's a little inelegant, but may be the simplest way to go about this.
Alternately, the info you need
is in the class file, in a format which is
not platform- or classloader-dependent. You can parse the class file directly to find out the class and package info. It's possible to do this yourself by studying the
class file format a bit. But it's probably a bit tedious, as you need to read in the entire constant table first, consisting of a number of different structures of varying length. Then you can get to the this_class field, which tells you which of the structures in the previous constant table identified the class.
Or, you could use something like
BCEL to parse this for you. Glancing through their cleverly-hidden API :roll: , this could be as simple as new ClassParser(fileName).parse().getPackageName(). Or not - as I recall from limited experience (and comments of others), BCEL can have its share of frustrating gotchas. Still, it may well be the easiest solution here if you don't mind adding the third-party jar to your project.