É possível misturar –class-path e –module-path em javac (JDK 9)?

Quando eu compilo um módulo que depende de outros módulos que eu compilei anteriormente, eu tenho que especificar a opção --module-path . Isso faz com que os módulos dependam do visível.

Mas, ao mesmo tempo, também gostaria de tornar visíveis alguns arquivos Jar não modulares. No entanto, se não fizer deles módulos automáticos e apenas especificar o --class-path some.jar ao lado de --module-path , então o javac parece ignorar o claspath e lança “package yyy not found” e outros Erros “não encontrados”.

Eu posso entender que usar --class-path e --module-path na mesma (compilation) hora é ilegal, mas o javac não me avisa de qualquer maneira.

Você pode usar o caminho da class e o caminho do módulo em paralelo, mas há alguns detalhes a serem considerados.

Caminho do Módulo de Dependência ~> Caminho da Classe

Módulos explícitos (JARs com um descritor de módulo no caminho do módulo) não podem ler o módulo sem nome (JARs no caminho da class) – isso foi feito intencionalmente para evitar que os JARs modulares dependessem do “caos do caminho da class”.

Como um módulo deve requerer todas as suas dependencies e essas só podem ser atendidas por outros módulos nomeados (ou seja, não JARs no caminho de class), todas as dependencies de um JAR modular devem ser colocadas no caminho do módulo. Sim, mesmo JARs não modulares, que serão transformados em módulos automáticos .

O interessante é que os módulos automáticos podem ler o módulo sem nome, para que suas dependencies possam seguir o caminho da class.

Caminho da Classe de Dependência ~> Caminho do Módulo

Se você compilar código não modular ou ativar um aplicativo a partir de um JAR não modular, o sistema do módulo ainda estará em execução e, como o código não modular não expressa nenhuma dependência, ele não resolverá os módulos do caminho do módulo.

Portanto, se o código não modular depender de artefatos no caminho do módulo, você precisará adicioná-los manualmente com a opção --add-modules . Não necessariamente todos eles, apenas aqueles de que você depende diretamente (o sistema de módulos puxará dependencies transitivas) – ou você pode usar ALL-MODULE-PATH (verifique o post vinculado, isso é explicado em mais detalhes).

Eu acredito que usar as --classpath e --module-path ao mesmo tempo não é ilegal . É possível usar os dois ao mesmo tempo que, mesmo quando você não especifica explicitamente um caminho de class, o padrão é o diretório atual.

Detalhes da mensagem javac -help e ferramentas javac docs –

 --module-path , -p  

Especifique onde encontrar os módulos do aplicativo

 --class-path , -classpath , -cp  

Especifique onde encontrar arquivos de class de usuário e processadores de anotação

Se --class-path , -classpath ou -cp não forem especificados , o caminho da class do usuário será o diretório atual .


Edit : Graças a @MouseEvent, eu provavelmente perdi a parte na questão

No entanto, se não torná-los módulos automáticos e apenas especificar o –class-path some.jar ao lado de –module-path, então javac parece ignorar o claspath e lança “pacote yyy não encontrado” e outro “não encontrado “erros.

Se você não torná-los automáticos, ele é tratado como um módulo sem nome do Module Module e –

Um módulo nomeado não pode, de fato, declarar dependência do módulo sem nome. Essa restrição é intencional, pois permitir que módulos nomeados dependam do conteúdo arbitrário do caminho da class tornaria a configuração confiável impossível.

Além disso, o módulo sem nome exporta todos os seus pacotes, portanto, o código em um módulo automático será capaz de acessar qualquer tipo público carregado a partir do caminho de class.

Mas um módulo automático que faz uso de tipos do classpath não deve expor esses tipos aos módulos explícitos que dependem dele , já que os módulos explícitos não podem declarar dependencies sobre o módulo sem nome.

Se o código no módulo explícito com.foo.app se referir a um tipo público em com.foo.bar , por exemplo, e a assinatura desse tipo se referir a um tipo em um dos arquivos JAR ainda no caminho da class , então o código em com.foo.app não será capaz de acessar esse tipo desde com.foo.app não pode depender do módulo sem nome.

Isso pode ser solucionado tratando com.foo.app como um módulo automático temporariamente para que seu código possa acessar tipos do caminho da class, até o momento em que o arquivo JAR relevante no caminho da class possa ser tratado como um módulo automático ou convertido em um módulo explícito.