Скомпилируйте класс Java во время выполнения с зависимостями от вложенной банки

Хотя вы не упомянули об этом явно, я думаю, что вы используете версию Java с modules (JDK 9+), но руководства, которым вы следовали, относятся к более ранним версиям, начиная с Java 6. Вот почему вы получаете сообщение об ошибке о неподдерживаемом listLocationsForModules, потому что разработчики JDK модернизировали FileManager с с методами по умолчанию, которые выдают UnsupportedOperationException.

Если вы на самом деле не хотите использовать версию Java выше 8, я бы остановился на JDK8, это будет намного проще!

Я продолжу предполагать, что вы хотите использовать Java 9 и выше (протестировал мой код на Java 11), однако:

Для работы с модулями достаточно, чтобы ваш файловый менеджер делегировал стандартному файловому менеджеру:

@Override
public Location getLocationForModule(Location location, String moduleName) throws IOException {
    return standardFileManager.getLocationForModule(location, moduleName);
}

@Override
public Location getLocationForModule(Location location, JavaFileObject fo) throws IOException {
    return standardFileManager.getLocationForModule(location, fo);
}

@Override
public Iterable<Set<Location>> listLocationsForModules(Location location) throws IOException {
    return standardFileManager.listLocationsForModules(location);
}

@Override
public String inferModuleName(Location location) throws IOException {
    return standardFileManager.inferModuleName(location);
}

Я также счел необходимым изменить код Atamur, чтобы явно проверять базовый модуль java (чтобы мы могли разрешать java.lang в Java 9+!) и делегировать стандартному файловому менеджеру, как вы бы сделали для пути к классу платформы в предыдущем версии:

@Override
public Iterable<JavaFileObject> list(Location location, String packageName, Set<JavaFileObject.Kind> kinds, boolean recurse) throws IOException {
    boolean baseModule = location.getName().equals("SYSTEM_MODULES[java.base]");
    if (baseModule || location == StandardLocation.PLATFORM_CLASS_PATH) { // **MODIFICATION CHECK FOR BASE MODULE**
        return standardFileManager.list(location, packageName, kinds, recurse);
    } else if (location == StandardLocation.CLASS_PATH && kinds.contains(JavaFileObject.Kind.CLASS)) {
        if (packageName.startsWith("java") || packageName.startsWith("com.sun")) {
            return standardFileManager.list(location, packageName, kinds, recurse);
        } else { // app specific classes are here
            return finder.find(packageName);
        }
    }
    return Collections.emptyList();

}

Обновления

Некоторые другие моменты:

Извлечение встроенных классов загрузки Spring:

Получите jarUri, найдя последний индекс '!' в каждом URL-адресе packageFolder, как в Комментарий Тэюн Ким и не первый, как в исходном примере.

 private List<JavaFileObject> processJar(URL packageFolderURL) {
  List<JavaFileObject> result = new ArrayList<JavaFileObject>();
  try {
    // Replace:
    // String jarUri = packageFolderURL.toExternalForm().split("!")[0];
    // With:
    String externalForm = packageFolderURL.toExternalForm();
    String jarUri = externalForm.substring(0, externalForm.lastIndexOf('!'));


    JarURLConnection jarConn = (JarURLConnection) packageFolderURL.openConnection();
    String rootEntryName = jarConn.getEntryName();
    int rootEnd = rootEntryName.length()+1;
    // ...

Это позволяет пакету PackageInternalsFinder возвращать CustomJavaFileObject с полными URI классам во встроенных банках spring (под BOOT-INF/lib), которые затем разрешаются с помощью spring boot jar Обработчик URI, который регистрируется аналогично тому, как описано в этом ответе. Обработка URI должна происходить автоматически через весеннюю загрузку.