É possível compilar Java no código da máquina? (Não é bytecode)


32

Você pode compilar o Java diretamente no código da máquina?

Quero fazer isso para ter controle sobre quais plataformas são usadas e não sei C, C ++ etc.

Respostas:


36

Parece que o GNU Compiler for Java pode converter o código-fonte Java em bytecode Java ou código de máquina. Ele também pode converter o bytecode Java existente em código de máquina. No entanto, as últimas notícias são de 2009, então não tenho certeza de quão atual é e se ele pode lidar com os recursos mais recentes da linguagem Java.


1
Se o bytecode Java não mudou desde 2009, isso ainda deve funcionar sem que os desenvolvedores acenem com o sinal "Ei! Ainda estou aqui" sobre o software.
Robert Harvey

@RobertHarvey Acredito que o Java 7 introduziu alguns novos conceitos de linguagem, por isso pode falhar na conversão dos arquivos de origem em código de máquina. Se o bytecode também mudou com esses novos recursos, isso também falharia
Thomas Owens

1
O Excelsior JET parece ainda estar ativo (comercial). Havia o Fujitsu TowerJ, mas isso parece ter morrido há uma década e era bastante inútil naquela época.
Tom Hawtin - defina

Eu estou usando java 6 de modo java 7 não é problema no meu caso
Russell

1
O site da GCJ diz que não suportava totalmente nem o Java 1.5. Veja esta discussão: stackoverflow.com/a/4040404/1257384
GregT

13

Não respondendo diretamente ao OP, mas talvez um aparte interessante. Java pode ser executado em três modos:

  1. Misto (padrão) - Uma combinação de código compilado Interpretado e Máquina (máquina compilada == compilada pelo JIT em tempo de execução)
  2. Com -Xintsinalizador - Interpretado - Somente código de bytes
  3. Com -Xcompbandeira - Compilado - máquina compilada

1
@ Martjin São para o HotSpot? Por acaso, você tem referência para isso -Xcompporque eu não consegui encontrá-lo na documentação do JDK 7 ou na documentação das opções do HotSpot e não tenho certeza se você tem alguns segredos ocultos da lista de discussão que nós, meros mortais, não conhecemos :-)
Edalorzo 30/10/12

2
É uma opção deliberadamente oculta sim :-). Existem várias listas de discussão openjdk (openjdk.java.net) você pode recolher este tipo de informação - ou ler o código fonte :-)
Martijn Verburg

Observe que, de acordo com meus testes, o -Xcomp pode ter um desempenho inferior (por um fator de dois) em alguns casos.
precisa

Bem, sim. Otimizações just in time são difíceis de fazer quando o JIT nem está em execução. Pode ter! = Terá.
candied_orange

ummm, então estas são opções para javac? ao usar o -Xcomp, por padrão, gera um único arquivo binário?
Alexander Mills

7

Talvez seja melhor detectar o sistema operacional usando System.getProperty (“os.name”) . Isso permitiria escolher oferecer suporte a mais de um sistema operacional, mas excluir outros.


Existe uma maneira de isso ser enganado / jogado?
FrustratedWithFormsDesigner

@ Frustrado, provavelmente, mas eu estava assumindo que sua intenção era impedir oficialmente o suporte a sistemas operacionais que ele não testou. Não faz sentido desabilitar intencionalmente a portabilidade, você fica essencialmente livre.
Karl Bielefeldt

Também pode ser que ele queira vincular o programa a hardware específico de uma maneira independente do SO.
FrustratedWithFormsDesigner

Você pode forçar "os.name" propriedade do sistema usando argumentos especiais para a JVM: java -Dos.name=MacOS.
SkyDan

2

Agora é: GraalVM permite que você compile seus programas com antecedência em um executável nativo. Dê uma olhada no recurso de imagem nativa :

Pergunta relacionada: 'Posso compilar Java para código nativo?' https://stackoverflow.com/questions/2991799/can-i-compile-java-to-native-code/50555050#50555050


PS GCJ não é mais mantido.
Fonte: 'A exclusão do gcj' http://tromey.com/blog/?p=911

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.