javaman00 wrote:Gostaria de saber qual é o motivo que algumas pessoas como Delphi, VB, PHP e outros... falam que o JAVA é interpretado!?!?!?

renato3110 wrote:Porque o .class não é código de máq.?

javaman00 wrote:Gostaria de saber qual é o motivo que algumas pessoas como Delphi, VB, PHP e outros... falam que o JAVA é interpretado!?!?!?

fenrir wrote:

renato3110 wrote:Porque o .class não é código de máq.?

Pergunta ambígua! [...]

Posto isso, vamos lá. Há basicamente dois casos em que se usa "por que". Num deles, pouco comum, temos a equivalência com as expressões "pelo/a qual", "pelos/as quais": "São indescritíveis os caminhos por que (= pelos quais) tivemos de passar"; "As teses por que (= pelas quais) luto nem sempre são compreendidas". No outro caso, o "por que" equivale a "por que razão", "por qual razão": "Por que (= por que razão, por qual razão) no Brasil não se consegue criar uma sociedade mais justa e equilibrada?"; "Faço questão de saber por que (= por que razão, por qual razão) você é tão áspero com ela".

Já o "porque" ("junto") introduz explicação ou causa do que se afirma: "Não vou porque estou doente"; "Não voto nele porque seus projetos sociais são pífios".

pcalcado wrote:...

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

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)

louds wrote: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.