Dúvida teórica - JVM acessa diretamente o hardware?

a JVM acessa utilizando a API do sistema operacional,
por isto que existe uma JVM para cada SO

…mesmo pq em muitos sistemas operacionais vc nem tem permissão pra acessar diretamente o hardware (em qualquer Unix que se preze, por exemplo)

não tem pq a JVM acessar diretamente o hardware, já que é multi-plataforma, oque significa acessar o hardware do pc, mac, servidores sun, dec, ibm, intel, etc…
Porem isso não significa que basta portar a JVM para 1 SO que ele vai funcionar para todo hardware suportado por ele, já que ela gera código nativo para o hardware em questão.

Moral da historia, a JVM precisa ser portada para todas combinações de SO/hardware.

“skyblue”:

Um professor meu falou que ele utiliza o Sistema Operacional, mais eu duvido um pouco disso porque se ele é multi-plataforma, é mais simples acessar o hardware do que utilizar as funções de cada sistema. :?:

Na verdade o acesso ao hardware eh uma das funcoes do sistema operacional. Se voce escrver uma JVM que acessa o hardware direto, voce vai ter escrito um SO. Isto ia ser muito show !!! Tipo no teu bootloader voce ia poder escolher linux, hurd, windows ou java

A JVM pra lego mindstorm acessa direto o hardware, apesar de não ser exatamente um SO.

Qual SO que tem no lego mindstorm?

Srs.

A JVM é uma componente de software composta de várias camadas de software…

Em algumas implementações ela acessa diretamente o Hardware sim, sem passar por um OS.

A JVM tradicional que conhecemos, e que usamos em 99% dos nossos sistemas, está baseada nas APIs dos OSs disponíveis no mercado.

A JVM segue uma especificacao clara, entretanto a sua implementação pode ser até em hardware e não necessiaremente software.

Entretanto, o objetivo dela é fornece o ambiente de execução de software Java. Por isso, essa questão é irrelevante…

No caso de automação comercial, um sistema Java-based vai ter que fazer acesso á dispositivos de hardware, como impressoras fiscais, balanças, e etc. Para isso é necessário construir uma cada em Java usando JNI para acessar compoenentes em C/C++ que acessam esses dispositivos.

[]'s

[color=“blue”]Oi pessoal !!! Tem outra questão aqui que eu também acho interessante e gostaria de debater aqui… tem alguma vantagem dos programas java serem interpretados e não compilados ? :?:

Eu acho que uma grande desvantagem é que os programas em java ficam muito lentos… eu não vejo nenhuma grande vantagem nisso. :?

Valeu pessoal !!!
Skyblue[/color]

A menos que vc esteja falando do BeanShell 2.0, nenhum código java é verdadeiramente interpretado - vc sempre compila ele pra bytecodes, e só isso já salva um boooom trabalho do ambiente de execução.

Mas, de qualquer forma, as VMs (e eu estou falando das VMs “desktop” aqui, apenas) têm de interpretar o bytecode. Só que as VMs modernas fazem mais do que isso - elas compilam o bytecode para código de máquina nativo usando um compilador JIT - Just-In-Time, que só têm mesmo o trabalho de transformar em código nativo aquilo que interessa - código que é muito acessado, por exemplo, dentro de um loop.

A vantagem disso é que o JIT, apesar de não poder perder muito tempo com algumas otimizações mais “caras”, pode otimizar o código à medida em que ele vai sendo executado, mantendo a independencia de plataforma, e, apesar de a tecnologia empregada nos JITs hoje ainda não ser a melhor existente (pra isso existem projetos como a Jikes RVM), eles podem em muitos casos gerar código mais rápido do que um compilador tradicional faria.

Jikes RVM: http://www-124.ibm.com/developerworks/oss/jikesrvm/

Ai ai ai… Java é lento em relação ao quê!!! Sim, Java é mais lento do que Fortran em aplicações matemáticas, mas Fortran faz parte de um outro paradigma, assim como C. Logo não vale comparar ambas tecnologias. Com relação a C++, o desempenho de ambos é bem próximo, devido à otimizações que JITters como Hotspot e JRockit fazem. Mas, ok, vamos dizer que Java seja uma carroça puxada por um burro manco. Qual é a vantagem de se criar códigos interpretados e lentos?? A vantagem que você tem é ter códigos objetos portáveis e possíveis de serem executados sem necessidade de recompilação em inúmeras plataformas. E isso traz outras consequências, como permitir que códigos sejam baixados de outras VMs em tempo de execução e linkados dinamicamente ao seu programa com uma performance pra lá de razoável. Além disso, códigos “interpretados” tendem a ser mais seguros do que os nativos, uma vez que os bytecodes rodam sobre uma camada que protege o SO de acessos indevidos a recursos.
Pois bem, bytecode é mais lento do que nativo? Sim, óbvio que é. Mas, pense no trade-off segurança-portabilidade-flexibilidade X desempenho e você verá que, em 90% dos casos, desempenho é até algo que pode ser relevado em função dos benefícios do bytecode. Além disso, se você achar que o burro manco está lento demais, hoje em dia você pode colocar este burro manco dentro de um vagão de um trem e fazer o trabalho mais rápido, ou seja, você pode comprar uma máquina mais potente, uma vez que recursos como CPU e memória estão muito mais baratos (apesar do dólar insistir em ficar na casa do R$2,96).

Ahhh, e chega por enquanto.

As vantagens de utilizar 1 representação intermediaria são portabilidade, teu class funciona em qualquer maquina que tenha uma JVM; compatibilidade binaria, alterar os fields da tua classe não exige recompilar todos usuarios dela; compatibilidade de ABI, ou melhor, uma ABI perde seu sentido, ou seja , uma classe compilada com o javac da Sun vai funcionar direito com outra compilada com o jikes.