Gostaria de saber qual é o motivo que algumas pessoas como Delphi, VB, PHP e outros… falam que o JAVA é interpretado???
Palo que eu saiba… intepretado é o PHP e quando quero rodar um “.java” preciso compilar o garoto…
E ai galera, opiniões???
JAVA-Porque todo mundo teima(Principalmente quemnão meche com java...)que a liguagem é intepretada!?
Sim, precisa compilar… pra gerar o bytecode, o qual é INTERPRETADO pela JVM. O bytecode não é um código diretamente executável pelo sistema operacional, o que dependeria da arquitetura do sistema, isso é, não é portável. O Java garante portabilidade sendo interpretado pela JVM. Assim, vc só precisa ter uma JVM específica para cada sistema operacional e pronto, seu código teoricamente roda em qualquer lugar 
Eu nunca vi niguem falando que java é interpretado.
Mas deve ser porque é uma linguagem hibrida.
Em linguagens de programação híbridas, o compilador tem o papel de converter o código fonte em um código chamado de byte code, que é uma linguagem de baixo nível. Um exemplo deste comportamento é o do compilador da linguagem Java que, em vez de gerar código da máquina hospedeira (onde se está executando o compilador), gera código chamado Java Bytecode.
Wikipédia - http://pt.wikipedia.org/wiki/Compilador
Porque o .class não é código de máq.?
Pergunta ambígua!
Porque? O .class não é código de máq.?
Não, o .class não é código de máquina. Como disseram, é um bytecode que depois é interpretado pela VM.
Porque o .class não é código de máq.?
Porque se fosse código de máquina, o Java não seria multiplataforma! Um programa compilado no Linux não vai rodar no Windows nem no MacOS. Mas um programa em Java criado no MacOS (por exemplo) vai rodar em qualquer plataforma que tenha uma JVM disponível.
[quote=javaman00]Gostaria de saber qual é o motivo que algumas pessoas como Delphi, VB, PHP e outros… falam que o JAVA é interpretado???
[/quote]
Acho que ela não é interpretada, porque o JVM não trata direto o arquivo.java(o Fonte) e sim o byte code, que já vem mastigado.Assim é o meu entender.
E que diferenca faz na pratica se Java eh interpretada ou nao?
O treco roda numa maquina. Virtual, mas eh uma maquina, e a grande maioria do pessoal que eu vejo discutindo isso nao faz a menor ideia de como ela funciona, e tambem nao ta muito ai pra saber… entao, pra que discutir? Abre logo uma cerveja e pronto, vah 
Além do fonte não ser interpretado, a VM compila o bytecode p/ código nativo internamente (pelo menos as partes que ela identifica ser interessante…).
Já é assim há muito tempo.
Infelizmente essa fama (ainda) continua sendo espalhada no boca-a-boca por pessoas sem conhecimento do assunto…
Pergunta ambígua! […][/quote]
Não é uma pergunta, é uma resposta
java -Xint => o Java desliga o "just in time compiler" e roda só o interpretador
java -Xcomp => o Java desliga o interpretador e roda só o "just in time compiler"
Não use nenhuma dessas opções acima, deixam seu código mais lento nos dois casos.
Deixe o Java tomar conta disso por você. Ele interpreta código menos usado, e quando ele vê que o código é mais usado, roda o "just in time compiler" para torná-lo mais rápido.
Sendo chato pra ajudar a manter o Manuel mais bonito.
Huuahuauahuha de novo isso 
Ainda bem que eu escrevi certo xD
Mas Deus todo poderoso !!!
Para aqueles que não sabem ainda, leiam aqui uma explicação pra lá de detalhada e explicativa sobre o Java:
[quote]Máquina Virtual Java
Programas Java não são traduzidos para a linguagem de máquina como outras linguagens estaticamente compiladas e sim para uma representação intermediária, chamada de bytecodes.
Os bytecodes são interpretados pela máquina virtual Java (JVM - Java Virtual Machine). Muitas pessoas acreditam que por causa desse processo, o código interpretado Java tem baixo desempenho. Durante muito tempo esta foi uma afirmação verdadeira. Porém novos avanços tem tornado o compilador dinâmico (a JVM), em muitos casos, mais eficiente que o compilador estático.
Java hoje já possui uma performace próxima do C++. Isto é possível graças a otimizações como a compilação especulativa, que aproveita o tempo ocioso do processador para pré-compilar bytecode para código nativo. Outros mecanismos ainda mais elaborados como o HotSpot da Sun, que guarda informações disponíveis somente em tempo de execução (ex.: número de usuários, processamento usado, memória disponível), para otimizar o funcionamento da JVM, possibilitando que a JVM vá “aprendendo” e melhorando seu desempenho. Isto é uma realidade tão presente que hoje é fácil encontrar programas corporativos e de missão crítica usando tecnologia Java. No Brasil, por exemplo, a maioria dos Bancos utiliza a tecnologia Java para construir seus home banks, que são acessados por milhares de usuários diariamente. Grandes sites como o eBay utilizam Java para garantir alta performace. E a cada ano Java tem se tornado mais rápido, na medida que se evolui o compilador dinâmico.
Essa implementação no entanto tem algumas intrínsicas. A pré-compilação exige tempo, o que faz com que programas Java demorem um tempo significamente maior para começarem a funcionar. Soma-se a isso o tempo de carregamento da máquina virtual. Isso não é um grande problema para programas que rodam em servidores e que deveriam ser inicializados apenas uma vez. No entanto isso pode ser bastante indesejável para computadores pessoais onde o usuário deseja que o programa rode logo depois de abri-lo.
O Java ainda possui uma outra desvantagem considerável em programas que usam bastante processamento numérico. O padrão java tem uma especificação rígida de como devem funcionar os tipos numéricos. Essa especificação não condiz com a implementação de pontos flutuantes na maioria dos processadores o que faz com que o java seja significativamente mais lento para estas aplicações quando comparado a outras linguagens.
Os bytecodes produzidos pelos compiladores Java podem ser usados num processo de engenharia reversa para a recuperação do programa-fonte original. Esta é uma característica que atinge em menor grau todas as linguagens compiladas. No entanto já existem hoje tecnologias que “embaralham” e até mesmo criptografam os bytecodes praticamente impedindo a engenharia reversa[/quote]
Fonte: wikipedia
Dando uma de advogado do diabo. O código fonte Java é compilado para uma representação intermediaria que não código de máquina - o tal do bytecode.
A JVM é um interpretador deste bytecode, executando ele. Se esse interpretador gera código nativo durante sua execução, ou se ele chama o papa, é um detalhe da implementação.
Simples assim, java é uma linguagem interpretada. O problema não está nesta afirmação, que é correta, mas sim nas pessoal de tormarem por ela uma conotação ruim de baixa performance. Linguagens intepretadas hoje não perdem nada em termos de performance p/ linguagens compiladas direto para código de máquina.
Java é definido como: Linguagem Híbrida.
Ela é tanto compilada como interpretada.
[quote=louds]Dando uma de advogado do diabo. O código fonte Java é compilado para uma representação intermediaria que não código de máquina - o tal do bytecode.
A JVM é um interpretador deste bytecode, executando ele. Se esse interpretador gera código nativo durante sua execução, ou se ele chama o papa, é um detalhe da implementação.
Simples assim, java é uma linguagem interpretada. O problema não está nesta afirmação, que é correta, mas sim nas pessoal de tormarem por ela uma conotação ruim de baixa performance. Linguagens intepretadas hoje não perdem nada em termos de performance p/ linguagens compiladas direto para código de máquina.[/quote]
Linguagens interpretadas, estritamente falando (uau), analisam o código-fonte, como em Ruby…
resumindo a discução… JAva é compilado e interpretado…
Funcionaria assim:
".JAVA" (FONTE JAVA)
II
V
".CLASS" (JAVA BYTECODE)
II
V
"JVM" (LE O JAVA BYTECODE E GERA O BYTECODE DA MAQUINA)
II
V
"MAQUINA" (LE O BYTECODE BASEADO NA JVM EM QUESTÃO)
Agora uma pequena dúvida …
no JAVA na fase INTEPRETADA dele… poderia ser ruin em performance como um PHP???(Não que o PHP seje lento!, que não é!, lembrando que no PHP 6.0 sera compilado!)
A performance ‘do Java’ depende da implementacao da JVM, nao da simplesmente pra dizer que ‘eh mais rapido que X ou mais lento que Y’.
Dito isto, a JVM da Sun, nas 3 plataformas em que ela eh disponibilizada (Windows, Solaris e Linux), tende a ser consistentemente mais rapida que o runtime do PHP para tarefas comuns (e provas disso estao pra todo lado na net, fica como licao de casa usar o Google pra descobrir).
E repetiram, repetiram… Repetiram e repetiram que o código compilado gera uma .class que contém o bytecode para ser interpretado pelo JVM que é a forma de tornar o Java ‘rodável’ em qualquer máquina com qualquer S.O.
Mas então, É ou Não é? Já é ou Já era?
Depois de ler todos os comentários, só posso dizer que é interpretada, mas que seus comentaristas erram em não se aprofundar mais antes de dizer isso para poder adicionar umas linhas explicando como funciona o processo de interpretação.
Porém como programadores de Java, esse comentário, mais os comentários de que Java é ‘lerdo’, e outras, não deveria ser continuada nas rodadas de conversas pois, quem faz um programa ser funcional/rápido, inteligênte/único é nada mais nada menos do que o Programador que acredita na sua linguagem
fim.