Пакетный файл с расширением (вызов Java) подстановочный знак работает на одном компьютере с Win 7, отказывает на другом

Question

Я использую пакетный файл Windows для запуска Java-программы, используя расширение с подстановочными знаками, чтобы установить загрузку JAR-файлов в classpath, как показано ниже:

java -cp "MyLibFolder\*" com.stupid.StupidProgram parm1

(Кавычки необходимы для Windows согласно этому вопросу StackOverflow.)

Это отлично работает на моем Win 7 машине x64 Home Premium дома, и работал отлично на моем рабочем компьютере (Win 7 x64 Enterprise). Однако теперь на моем рабочем компьютере выдается ошибка, в которой говорится, что он пытается найти основной класс в одном из JAR-файлов в расширении classpath.

Если MyLibFolder содержит a.jar, b.jar, ...., z.jar , ошибка заключается в том, что он не может найти основной класс в b.jar .

После некоторых экспериментов кажется, что он действует так, как если бы двойные кавычки были удалены, т.е. он действует на

java -cp a.jar b.jar c.jar [...] z.jar com.stupid.StupidProgram parm1

вместо

java -cp "a.jar b.jar c.jar [...] z.jar" com.stupid.StupidProgram parm1

Может кто-нибудь сказать мне, почему это может происходить на одном ПК с Win 7, а не на другом? (Пакетный файл идентичен, передается через контроль версий.)

Редактировать: Ага! Если я запускаю его через cmd.exe в папке Windows SysWOW64 (вместо system32 который я получаю, когда запускаю cmd по умолчанию или - казалось бы, - дважды щелкнув командный файл), он работает. Насколько я понимаю (например, из этого вопроса Microsoft Ответы), это то, что он запускает 32-битный cmd вместо 64-битного по умолчанию (хотя местоположения exe, кажется, кричат наоборот!). Я думаю, мне все еще нужно понять, почему это работает (почему это должно относиться к цитированию?), И почему существуют различия между двумя компьютерами.

Редактировать 2: На самом деле, запуск его через 32-битный cmd.exe вызвал другие проблемы в Java, который выполнялся: см. Этот поток SVNKit. (Я предполагаю, что это вызвало какую-то проблему с разрешениями файловой системы.) Мне пришлось обойти это, изменив командный файл, чтобы вручную развернуть все lib JAR. Я все еще хотел бы понять проблему, хотя ...

Answer 1

Это была ошибка в JDK/JRE, исправленная в 7u10 (я использовал 7u9): см. Примечания к выпуску 7u10 и отчет об ошибке.

Мне следовало бы более внимательно посмотреть на то, что мне говорили симптомы: это Java («предварительная обработка»), который выполняет расширение с подстановочными знаками, а не Windows, и он делал расширение, но затем, по-видимому, пропуская точки с запятой или аналогичные, чтобы Java затем увидел -cp a.jar b.jar [other stuff] вместо -cp a.jar;b.jar;[...];z.jar [class to run] .

Как упоминалось в отчете об ошибке, очевидно, что обходной путь должен использовать -cp "MyLibFolder/*;" (т. е. включить трейлинг ; подстановочный знак).