1. dump all the jars to get a list of classes and create a map: class to "jars".
2. Then try to compile the class and note the missing classes.
3. Look up the jars that contain the missing classes in your class to jar map.
4. And presto: you have your class path

If that is still too many jars, you can always run it through an optimization algorithm that tries to find the smallest combination of jars that include all classes, but you should at least have much smaller starting set. All combinations of up to 5 elements selected from a pool of 3000 is a *lot* of combinations to try out.

Best, beth

Far saner would be to try removing one path at a time until you have identified only the necessary include paths. That would require 3000 steps. I believe that Java searches from the first to the last path for stuff, in which case removing the last path would be the first thing to try.

If you believe that only a small handful of these 3000 are needed, then you could do a binary search for that handful. The idea here looks something like this untested code:

{
  my @untested_blocks;
  my @needed_paths;

  sub test_all_paths {
    @needed_paths = @untested_blocks = ();
    _test_all_paths(@_);
    return @needed_paths;
  }

  sub _test_all_paths {
    my @to_test = @_;

    return unless @to_test;

    # Mark the first half as not to test.
    push @untested_blocks, [splice @to_test, 0, int(@to_test/2)];

    # Find needed blocks in second half recursively
    if (not path_works( (map @$_, @untested_blocks), @needed_paths ) {
      if (1 == @to_test) {
        push @needed_paths, @to_test;
      }
      else {
        _test_all_paths(@to_test);
      }
    }

    # Find needed paths in the untested block we just added
    _test_all_paths( @{ pop @untested_blocks } );
  }
}
[download]

Why not simply remove paths one by one, instead of trying all 5-out-of-3000 combinations?

Just succesively remove paths, and every time it no longer works, put that path on the to-keep list...