Compilando e executando Java sem um IDE

Certa vez, no reddit.com , no tópico Compilando e executando Java sem IDE , foi feita a pergunta: Existe um comando que compila um grupo de arquivos Java que estão dentro de um pacote em uma pasta separada (vamos chamá-lo de bin ) e como eu iniciaria novos arquivos de classe? " O autor do tópico, kylolink , explica: "Quando comecei a usar Java, confiei no Eclipse para fazer toda a compilação para mim e estava apenas preocupado em escrever o código." Já vi essa pergunta muitas vezes e, de fato, esta foi o que me levou a postar no blog sobre sistemas GPS e IDEs: bons ou ruins?Eu adoro IDEs Java modernos e poderosos e eles tornam minha vida mais fácil no dia a dia, mas também há benefícios em saber como construir e executar exemplos simples de Java sem eles. Esta postagem é sobre como fazer exatamente isso. Em meu blog sobre como aprender Java com testes simples, escrevi sobre como às vezes gosto de usar um editor de texto simples e ferramentas de linha de comando para escrever, construir e executar aplicativos simples. tenho uma boa ideia agora de quanto "despesas gerais" meus IDEs Java favoritos exigem e tomo uma decisão antecipada se os benefícios alcançados com o uso da estrutura são suficientes para justificar as "despesas gerais". Na maioria das aplicações reais, não há dúvida de que o IDE VL vale muito. No entanto, para os exemplos de aplicações mais simples, nem sempre é esse o caso. O restante desta postagem mostra como construir e executar código Java sem um IDE para essas situações.

Escrevendo e executando código Java

Para deixar o exemplo mais claro, usarei algumas classes Java muito simples que estão relacionadas entre si por meio de composição ou herança e estão no mesmo pacote chamado dustin.examples . Duas classes estão faltando uma função main; a terceira classe, Main.java, tem uma função mainque permite demonstrar como executar a classe sem um IDE. Abaixo está o código para essas três classes: Parent.java

package dustin.examples;

public class Parent
{
   @Override
   public String toString()
   {
      return "I'm the Parent.";
   }
}

Filho.java

package dustin.examples;

public class Child extends Parent
{
   @Override
   public String toString()
   {
      return "I'm the Child.";
   }
}

Principal.java

package dustin.examples;

import static java.lang.System.out;

public class Main
{
   private final Parent parent = new Parent();
   private final Child child = new Child();

   public static void main(final String[] arguments)
   {
      final Main instance = new Main();
      out.println(instance.parent);
      out.println(instance.child);
   }
}

A captura de tela a seguir mostra a estrutura de diretórios com essas classes .java . A captura de tela mostra que os arquivos de origem estão na hierarquia de diretórios que representam o nome do pacote ( dustin/examples , porque as informações do pacote são dustin.examples ) e que este pacote reflete o diretório a hierarquia está no subdiretório SRC. Também criei um subdiretório classes (que atualmente está vazio) para armazenar os arquivos .class compilados para que o Javac não crie esse diretório quando ele não existir.

Construindo com JAVAC e executando com Java

Não importa a abordagem usada para criar código Java (Ant, Maven, Gradle ou IDE), em última análise, tudo se resume a JAVAC. As opções padrão na ferramenta de linha de comando JAVAC fornecida pela Oracle/Sun podem ser vistas executando JAVAC -help e opções de extensão adicionais podem ser visualizadas executando JAVAC -help -X. Mais detalhes sobre como usar essas opções podem ser encontrados na documentação da ferramenta JAVAC para Windows ou Unix/Linux. Como diz a documentação do Javac, a opção -sourcepath pode ser usada para expressar o diretório no qual existem os arquivos de origem. Na minha estrutura de diretórios mostrada na captura de tela acima, isso significa que, assumindo que estou executando o comando JAVAC no diretório C:\Java\examples\javacAndJava\ , eu teria que ter algo assim em meu comando: Javac -sourcepath src SRC\Dustin\examples\*. Java . A captura de tela a seguir mostra os resultados disso. Como não especificamos um diretório para os arquivos .class , eles foram colocados por padrão no mesmo diretório dos arquivos .java de origem dos quais foram compostos. Podemos usar a opção -dpara corrigir esta situação. Nosso comando pode ser executado agora, por exemplo, como Javac -sourcepath src -d classes src\Dustin\examples\*. Eu você . Conforme observado anteriormente, a pasta selecionada (classes) já deve existir. Quando isso acontecer, o comando colocará os arquivos .class na pasta especificada, conforme mostrado na captura de tela a seguir. Com os arquivos de origem Java compilados nos arquivos .class correspondentes no diretório especificado, podemos iniciar o aplicativo usando o menu de inicialização rápida do Ferramenta de linha de comando Java. Isso é feito simplesmente seguindo as instruções fornecidas nas páginas Java -help ou Java Tools e especificando a localização dos arquivos .class com a opção -classpath(ou -cp). O uso de ambas as abordagens para especificar o diretório de classes onde procurar os arquivos .class é demonstrado na captura de tela a seguir. O último argumento é o nome completo (pacote Java inteiro) da classe que possui a função principal a ser executada. Os comandos demonstrados na captura de tela a seguir são classes java -cp dustin.examples.Main e classes java -classpath dustin.examples.Main.

Construindo e executando com Ant

Para os aplicativos Java mais simples, é bastante fácil usar JAVAC e Java para criar e executar o aplicativo, respectivamente, conforme demonstrado. À medida que os aplicativos ficam um pouco mais complexos (por exemplo, código existente em mais de um pacote/diretório ou classes de dependência mais complexas em bibliotecas e estruturas de terceiros), essa abordagem pode se tornar complicada. Apache Ant é a mais antiga das "três grandes" ferramentas de construção Java e tem sido usada em milhares de aplicativos e implantações. Como eu disse em uma postagem anterior do blog, um arquivo de construção Ant muito simples é fácil de criar, especialmente se começar com um modelo como descrevi neste post. A lista de códigos a seguir é para o arquivo build.xml do Ant , que pode ser usado para compor arquivos .java em arquivos .class e então executar a classe dustin.examples.Main como foi feito acima com JAVAC e Java. construir.xml

<?xml version="1.0" encoding="UTF-8"?>
<project name="BuildingSansIDE" default="run" basedir=".">
   <description>Building Simple Java Applications Without An IDE</description>

   <target name="compile"
           description="Compile the Java code.">
      <javac srcdir="src"
             destdir="classes"
             debug="true"
      includeantruntime="false" />
   </target>

   <target name="run" depends="compile"
           description="Run the Java application.">
      <java classname="dustin.examples.Main" fork="true">
         <classpath>
           <pathelement path="classes"/>
         </classpath>
      </java>
   </target>
</project>

Não usei as propriedades Ant e não incluí os objetivos comuns que costumo incluir (como "pure" e "Javadoc") para manter este exemplo o mais simples possível e mantê-lo próximo ao exemplo anterior usando JAVAC e Java . Observe também que habilitei "debug" definido como "true" para a tarefa JAVAC Ant porque isso não é verdade no caso de falha do Ant, mas é verdade com o padrão do JAVAC. Não é de surpreender que a tarefa Javac e a tarefa Java Ant se assemelhem às ferramentas de comando JAVAC e ao Java. Porque usei o nome padrão Ant espera um arquivo de compilação quando não é especificado explicitamente (build.xml) e porque forneci o destino "Run" como o "padrão" para esta compilação e porque incluí "compile" como uma execução de dependência o alvo "Run" e como o Ant estava no caminho do meu ambiente, tudo o que tive que fazer na linha de comando foi fazer com que o Ant compilasse e executasse o exemplo do ant no diretório com o arquivo build.xml . Isso é mostrado na imagem a seguir. Embora eu tenha demonstrado compilar e executar um aplicativo Java simples com Ant, costumo compilar apenas com Ant e executar com Java (ou um script que chama Java se o caminho de classe for pesado).

Construindo e executando com Maven

Embora Ant tenha sido a primeira ferramenta central de construção Java, o Apache Maven eventualmente ganhou fama em grande parte devido à adoção de configuração baseada em convenções e suporte para repositórios de bibliotecas compartilhadas. O Maven é fácil de usar quando o código e os objetos gerados seguem seu layout de diretório padrão. Infelizmente, meu exemplo não segue essa estrutura de diretórios, mas o Maven nos permite substituir a estrutura de diretórios padrão esperada. A seguir está uma lista de código para um arquivo Maven POM que é usado no lugar dos diretórios de origem e destino e fornece os outros elementos mínimos necessários para uma construção do Maven usando o Maven 3.2.1. pom.xml

<project>
   <modelVersion>4.0.0</modelVersion>
   <groupId>dustin.examples</groupId>
   <artifactId>CompilingAndRunningWithoutIDE</artifactId>
   <version>1</version>

   <build>
      <defaultGoal>compile</defaultGoal>
      <sourceDirectory>src</sourceDirectory>
      <outputDirectory>classes</outputDirectory>
      <finalName>${project.artifactId}-${project.version}</finalName>
   </build>
</project>

Como o arquivo pom.xml acima define o "defaultGoal" de "compile" e porque os arquivos pom.xml são o POM personalizado padrão que o executável do Maven (MVN) procura e porque o diretório bin de instalação do Maven está no meu caminho, apenas Preciso executar "MVN" para compilar arquivos .class conforme mencionado na imagem a seguir. Também posso executar o aplicativo compilado do Maven usando o comando Mvn Exec: Java -Dexec.mainClass = dustin.examples.Main , que é observado na captura de tela a seguir. Assim como acontece com o Ant, tendo a não usar o Maven para executar meu aplicativo Java simples, mas em vez disso, uso Java em código compilado (ou uso um script que chama Java diretamente em classes longas).

Construindo e executando com Gradle

Gradle é a mais nova, moderna e elegante das três principais ferramentas de construção Java. Às vezes sou cético sobre a essência do que está na moda, mas descobri muitas coisas que gosto no Gradle (escrito em Groovy em vez de XML, suporte integrado ao Ant, suporte integrado ao Ivy, configuração por convenção que é fácil para reconfigurar, suporte ao repositório Maven e etc.). O exemplo a seguir mostra uma compilação Gradle que pode ser usada para compilar e executar um aplicativo simples, que é o principal exemplo de código desta postagem. Apresentei este exemplo adaptado no blog Simple Gradle Java Plugin Customization. construir.gradle

apply plugin: 'java'
apply plugin: 'application'

// Redefine where Gradle should expect Java source files (*.java)
sourceSets {
    main {
        java {
            srcDirs 'src'
        }
    }
}

// Redefine where .class files are written
sourceSets.main.output.classesDir = file("classes")

// Specify main class to be executed
mainClassName = "dustin.examples.Main"

defaultTasks 'compileJava', 'run'

As duas primeiras linhas do arquivo build.gradle indicam o uso do plugin Java e do plugin Application, resultando em um monte de funcionalidades sendo incorporadas automaticamente nesta compilação. Definir "sourceSets" e "sourceSets.main.output.classesDir" permite substituir os diretórios Java padrão do plug-in Gradle para código-fonte Java e classes binárias compiladas, respectivamente. "MainClassName" permite especificar explicitamente qual classe deve ser executada dentro do Plugin de aplicativo. A linha "defaultTasks" define as tarefas que serão executadas simplesmente digitando "Gradle" na linha de comando: 'compileJava' é a tarefa padrão fornecida pelo plugin Java e 'Run' é a tarefa padrão fornecida pelo plugin de aplicativo. Como nomeei os assemblies build.gradle e é por isso que especifiquei as tarefas padrão como 'compileJava' e 'Run' e como tenho o diretório bin de instalação do Gradle em meu caminho, tudo que tive que fazer para construir e executar os exemplos foi digitar 'Gradle' e isso é demonstrado na imagem a seguir. Até o maior cético deve admitir que as compilações do Gradle são muito escorregadias para este exemplo simples. Combina a concisão de confiar em certas convenções e pressupostos com um mecanismo muito fácil para anular incumprimentos quando necessário. O fato de estar em Groovy ao invés de XML também é muito atrativo! Assim como acontece com Ant e Maven, tendo a construir apenas com essas ferramentas e a executar arquivos .class compilados diretamente de Java ou de um script que chama Java. A propósito, costumo também arquivar essas .classes em um jar para lançamento, mas isso está além do escopo deste artigo.

Conclusão

Muitas vezes, um IDE não é necessário para construir aplicativos e exemplos simples e pode ser ainda mais caro do que custa construir exemplos simples. Nesse caso, é muito fácil usar JAVAC e Java para construir e executar diretamente os exemplos. Como exemplos de envolvimento maior, uma ferramenta de construção como Ant, Maven ou Gradle torna-se mais atraente. O fato de muitos ambientes de desenvolvimento suportarem esses utilitários de construção significa que um desenvolvedor pode migrar para o IDE usando uma ferramenta integrada criada anteriormente no processo se for determinado que o suporte do IDE era necessário à medida que um aplicativo simples se transformava em um projeto completo. .