Arquivo em lote com expansão de caractere curinga (invocação Java) funciona em uma máquina Win 7, falha em outra

0

Estou usando um arquivo em lote do Windows para ativar um programa Java, usando a expansão de caractere curinga para definir uma carga de arquivos JAR no caminho de classe semelhante ao abaixo:

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

(As citações são necessárias para o Windows, conforme esta pergunta do StackOverflow .)

Isso funciona perfeitamente na minha máquina Win 7 x64 Home Premium em casa, e usado para funcionar bem no meu PC de trabalho (Win 7 x64 Enterprise). No entanto, ele agora gera um erro no meu PC de trabalho, dizendo que está tentando encontrar a classe principal dentro de um dos JARs na expansão do caminho de classe.

Se MyLibFolder contiver a.jar, b.jar, ...., z.jar , o erro é que não é possível encontrar uma classe principal em b.jar .

Após algumas experiências, parece que está agindo como se as aspas duplas tivessem sido removidas, ou seja, está agindo em

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

em vez de

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

Alguém pode me dizer por que isso pode estar acontecendo em um PC Win 7 e não o outro? (O arquivo em lote é idêntico, compartilhado por meio do controle de versão).

Editar : Aha! Se eu o executar via cmd.exe na pasta SysWOW64 do Windows (em vez do system32 que obtenho ao executar cmd por padrão ou --- parece --- clicando duas vezes no arquivo em lote), funciona. Meu entendimento (por exemplo, a partir desta pergunta do Microsoft Answers ) é que está executando ocmd de 32 bits em vez do padrão de 64 bits (embora os locais do exe parecem gritar o contrário!). Eu acho que ainda preciso entender por que isso funciona (por que isso deve estar relacionado com a citação?), E por que existem diferenças entre os dois PCs.

Editar 2 : Na verdade, executá-lo por meio do cmd.exe de 32 bits causou outros problemas no Java que estava sendo executado: consulte este tópico do SVNKit . (Eu acho que causou algum tipo de problema de permissões do sistema de arquivos.) Eu tive que trabalhar em torno dele, alterando o arquivo de lote para ter uma expansão manual de todos os JARs lib. Eu ainda gostaria de entender o problema ...

    
por Stuart Rossiter 26.06.2014 / 12:00

1 resposta

0

Foi um bug no JDK / JRE corrigido no 7u10 (eu estava usando o 7u9): veja o notas de versão 7u10 e o relatório de erros .

Eu deveria ter olhado com mais cuidado o que os sintomas me diziam: é Java ('pré-processamento') que faz a expansão curinga, não o Windows, e estava fazendo a expansão, mas presumivelmente omitindo ponto-e-vírgula ou similar de modo que Java, em seguida, viu -cp a.jar b.jar [other stuff] em vez de -cp a.jar;b.jar;[...];z.jar [class to run] .

Como mencionado no relatório de erros, aparentemente, uma solução alternativa é usar -cp "MyLibFolder/*;" (ou seja, incluir um ; com o caractere curinga)

.     
por 19.12.2014 / 13:41