JVM e bytecode

Existe outra forma de enviar uma seqüência de comandos para a JVM que não seja através de uma classe compilada ou gerada através de ferramentas de geração de código? Quero dizer, para qualquer coisa que queira fazer na JVM precisarei “empacotar” tudo dentro de uma Classe com o formato certinho?

Scripting API do Java 6?
Janino?

Opções são várias. Acho que o ideal era você descrever o que você precisa, e porque isto não existe hoje?

Sim. (Afinal porque alguem quereria mexer directamente na JVM?)
Existem ferramentas como profilers que recebem informações da JVM, tlv essas tenham alguma forma especial de ser criadas, mas de qq forma elas não enviam instruções da mesma forma que uma classe.

A scripting engine não faz nada por si mesma, você precisa usar proxies ou transformar o código em Java e compilá-lo. Aquilo é apenas um framework para “plugar” linguagens no Java.

Considerando-se o fato de que a JVM é uma máquina virtual, mas ainda uma máquina, e que os bytecodes são como o assembly de uma máquina real, por que não executar bytecodes diretamente? Se eu precisar gerar uma classe do zero para cada coisinha não haverá um overhead horrendo?

Estava pensando em implementar uma linguagem script, mas ainda estou estudando as possibilidades da JVM.

EDITADO: Por exemplo, se a linguagem permitisse tanto compilar quanto interpretar. Para compilar não haveria problema, pois poderia usar diversas formas, desde transformar aquilo para Java e compilar com a Compiler API ou usar alguma API de geração de código (BCEL, cglib, cojen, etc). Mas e para interpretar? Eu teria que compilar tudo por baixo dos panos ou usar proxies?

Você pode descrever isso com mais detalhes? Ainda não pesquei. Gerar código é necessário pro caso da JVM executar. Mas compreendo que o que queres é interpretar… Mas compreendendo o cenário, sem dúvida ficaria mais claro.

[quote=Thiagosc]A scripting engine não faz nada por si mesma, você precisa usar proxies ou transformar o código em Java e compilá-lo. Aquilo é apenas um framework para “plugar” linguagens no Java.
[/quote]
O q esta em script não é transformado para código Java, algumas linguagens de script tem o interpretador escrito em Java, outras em C usando JNI, ou outra forma qualquer, e executam os arquivos ou strings com o script, é uma alternativa a criar Class e poder alterar código dinamicamente em tempo real durante a execução, sem precisar para o programa, compilar, e rodar o programa de novo, é esta a vantagem do script, facilitar alterações e debug, usando o Java(JVM) por trás para fazer o trabalho sujo.

Vc responde a pergunta e depois faz a pergunta, repara, como vc disse a JVM é uma máquina virtual, na verdade uma plataforma estável independente do sistema operacional, onde nós fazemos programas para esta plataforma q no caso é em Java, sem precisar ficar amarrado ao sistema operacional, e os bytecodes ou .class, são tipo as dlls, e um .class com o método Main é o executavél, logo se isto é para uma maquina virtual, pra JVM como tu quer q seja interpretado como um código nativo pela máquina real? Não tem nada a ver uma coisa com a outra! A finalidade da JVM é manter uma plataforma estável para multiplos sistemas operativos, logo bytecodes e “assembly” não teem a mesma finalidade, vc esta confundindo a finalidade das coisas.

Meu existe várias, mas se tu quer implementar uma, avontade, mas existe varias, entenda q JVM é o core do Java, é o q entende o q é Java, e é o q consegue executar bytecodes, e compilar.

[quote=Thiagosc]
EDITADO: Por exemplo, se a linguagem permitisse tanto compilar quanto interpretar. Para compilar não haveria problema, pois poderia usar diversas formas, desde transformar aquilo para Java e compilar com a Compiler API ou usar alguma API de geração de código (BCEL, cglib, cojen, etc). Mas e para interpretar? Eu teria que compilar tudo por baixo dos panos ou usar proxies?[/quote]
Com o SDK vc pode compilar e executar! Linguagem q é transformar pra Java e depois é compilada?!?!? Tu já pensou a ginastica q isto é? Tu quer geração de código ou script, uma coisa não tem nada a ver com a outra!? JVM executa o Java, e existe algumas linguagens de script para Java, um código escrito em script Xpto, não é transformado pra Java, e sim executado no seu contexto pelo seu interpretador, escrito em Java ou não!

Script não tem nada a ver com gerar .class(bytecodes), uma coisa nao tem nada a ver com a outra, scripts uma coisa, java e .class outra, um não é convertido para outro, cada um roda independente ou juntos, via interpretadores para Java, por q Java é a plataforma estável aqui, é a base da coisa, o Script vem para tentar dar novas alternativas ao Java.

Não sei se consegui explicar bem, por q tu ta muito perdido e confundindo muito as coisas e é dificil assim, tenta usar o Java com uma IDE, tipo Netbeans ou Eclipse, e depois q entender o q é o Java e a sua finalidade, ai tu tenta aprender alguma linguagem de script q são tantas… e geração de código, não tem nada a ver com scripts… scripts não tem a finalidade de gerar .class, e sim serem executados pelo seu interpretador, q as vezes é escrito em Java ou adaptado ao Java…

Não, infelizmente não é possivel fazer isso. Esta é uma das maiores limitações da JVM, pois realmente não possui LCG (Lightweight Code Generation). A noticia ruim é que isso não deve ser mudado tão cedo. O problema todo vem do fato que não existe uma maneira de representar de eficientemente um método sem classe. Seria uma instancia de java.lang.reflection.Method? Péssima idéia, pois o custo de invocar seria muito alto. Sería feito algo semelhante a proposta de closures do Neal Gafter? Também ruim pois usa generics e devido a erasure sofreria um overhead grande por conta do boxing/unboxing.

Qual a solução para esse problema então? Introduzir suporte a delegates na linguagem. O .net possui delegates e na versão 2.0 existe LCG que pemite transformar um bloco de código em um delegate tranquilamente e vai sofrer GC assim com qualquer outro objeto, diferente das regras zuadas impostas pelos classloaders do Java.

No seu caso a solução é sim gerar toneladas de classes e ficar se matando para gerenciar quando deve dereferenciar o classloader, pois não existe suporte a classes livremente coletaveis em Java. Boa sorte, minha sugestão é você usar uma plataforma muito mais amigavel para scripting, use mono. Agora com a criação da DLR, é possivel desenvolver linguagens de script muito velozes com muito menos esforço que antes, dê uma olhada, vale a pena.

Não, infelizmente não é possivel fazer isso. Esta é uma das maiores limitações da JVM, pois realmente não possui LCG (Lightweight Code Generation). A noticia ruim é que isso não deve ser mudado tão cedo. O problema todo vem do fato que não existe uma maneira de representar de eficientemente um método sem classe. Seria uma instancia de java.lang.reflection.Method? Péssima idéia, pois o custo de invocar seria muito alto. Sería feito algo semelhante a proposta de closures do Neal Gafter? Também ruim pois usa generics e devido a erasure sofreria um overhead grande por conta do boxing/unboxing.

Qual a solução para esse problema então? Introduzir suporte a delegates na linguagem. O .net possui delegates e na versão 2.0 existe LCG que pemite transformar um bloco de código em um delegate tranquilamente e vai sofrer GC assim com qualquer outro objeto, diferente das regras zuadas impostas pelos classloaders do Java.

No seu caso a solução é sim gerar toneladas de classes e ficar se matando para gerenciar quando deve dereferenciar o classloader, pois não existe suporte a classes livremente coletaveis em Java. Boa sorte, minha sugestão é você usar uma plataforma muito mais amigavel para scripting, use mono. Agora com a criação da DLR, é possivel desenvolver linguagens de script muito velozes com muito menos esforço que antes, dê uma olhada, vale a pena.
[/quote]

Muito interessante, o reflection do .Net achei menos versátil do q o do Java pelo menos na versão 1.1, e quando precisei usar delegates não entendi muito bem o por q ser daquela maneira, agora ajudaste-me a compreender um pouco do por q.

O Mono tem dado grandes saltos, é sem dúvida uma ótima opção.

Só queria deixar uma nota q esta de gerar um “monte de classes”, é o q faz o Java ter o poder q tem, para grandes aplicações uma boa estrutura do código é essencial, enquanto q no .Net há uma liberdade maior para isto, como poder num arquivo ter diversas classes e namespaces, não ajuda nada a organizar, e mesmo se retirarmos as classes voltamos ao C não?

As estes monte de classes ajudam a organizar tudo, e quanto a Scripts acho q o Java esta muito bem servido neste ponto. To meio por fora dos scripts suportados no .Net/Mono.

Não, infelizmente não é possivel fazer isso. Esta é uma das maiores limitações da JVM, pois realmente não possui LCG (Lightweight Code Generation). A noticia ruim é que isso não deve ser mudado tão cedo. O problema todo vem do fato que não existe uma maneira de representar de eficientemente um método sem classe. Seria uma instancia de java.lang.reflection.Method? Péssima idéia, pois o custo de invocar seria muito alto. Sería feito algo semelhante a proposta de closures do Neal Gafter? Também ruim pois usa generics e devido a erasure sofreria um overhead grande por conta do boxing/unboxing.

Qual a solução para esse problema então? Introduzir suporte a delegates na linguagem. O .net possui delegates e na versão 2.0 existe LCG que pemite transformar um bloco de código em um delegate tranquilamente e vai sofrer GC assim com qualquer outro objeto, diferente das regras zuadas impostas pelos classloaders do Java.

No seu caso a solução é sim gerar toneladas de classes e ficar se matando para gerenciar quando deve dereferenciar o classloader, pois não existe suporte a classes livremente coletaveis em Java. Boa sorte, minha sugestão é você usar uma plataforma muito mais amigavel para scripting, use mono. Agora com a criação da DLR, é possivel desenvolver linguagens de script muito velozes com muito menos esforço que antes, dê uma olhada, vale a pena.
[/quote]

Muito interessante, o reflection do .Net achei menos versátil do q o do Java pelo menos na versão 1.1, e quando precisei usar delegates não entendi muito bem o por q ser daquela maneira, agora ajudaste-me a compreender um pouco do por q.

O Mono tem dado grandes saltos, é sem dúvida uma ótima opção.

Só queria deixar uma nota q esta de gerar um “monte de classes”, é o q faz o Java ter o poder q tem, para grandes aplicações uma boa estrutura do código é essencial, enquanto q no .Net há uma liberdade maior para isto, como poder num arquivo ter diversas classes e namespaces, não ajuda nada a organizar, e mesmo se retirarmos as classes voltamos ao C não?

As estes monte de classes ajudam a organizar tudo, e quanto a Scripts acho q o Java esta muito bem servido neste ponto. To meio por fora dos scripts suportados no .Net/Mono.
[/quote]

Acho que você não entendeu o problema. Não estamos falando de código fonte, não estamos falando de gerar código em runtime, no Java você precisa criar uma classe inteira quando quer apenas criar 1 novo método, no .NET um método pode ser construido para um delegate. Entendeu? Não estamos falando de como se programa com C# mas sim de geração em runtime. LCG é extremamente útil para ter dispatch rápido em linguagens dinâmicas. Recomendo você dar uma olhada no namespace System.Reflection.Emit, daí você vai ver como o Java está muitos anos atrasado quando o assunto é flexibilidade.

Java realmente possui mais linguagens de script, porém isso está mudando rápidamente e deve se inverter a favor do .NET no ano que vem. Com o advento da DLR, implementar linguagens dinâmicas ficou muito mais simples, veja que construiram uma implementação completa de ecma-script com pouco mais de 9mil linhas de código - conte o tamanho do rhino. Hoje para quem gosta de python e linguagens semelhantes, .NET tem IronPython (que é muito melhor que o Jython) e Boo. o IronRuby ainda está no começo, mas em pouco tempo estará em pé de igualdade com o jruby.

Muito bom saber disto louds!

Não sabia destes avanços, programo em Java e C#, mas tenho mais tendência para gostar e apostar no Java, mas tb sou doido para explorar mais afundo o Mono onde até agora tive apenas contato superficial, por causa do trabalho sou “obrigado” a usar M$ tools.

Vi estes dias num blog falando do IronRuby e esta mesmo muito promissor.

Tenho q arranjar um tempo para explorar mais o Mono e começar a usar com força.

Valew :wink: