Java, é simultaneamente plataforma e uma linguagem de programação?

Na verdade, o java consiste de três coisas separadas, apesar de elas se relacionarem fortemente entre si: A linguagem de programação, a API e a JVM.
A JVM está de certa forma bem amarrada a um subconjunto da API, e a linguagem de programação está amarrada um pouco a API (java.lang) e fortemente amarrada a JVM. No entanto, nem a JVM e nem a API estão amarradas a linguagem ou ao compilador.

O que o JRuby faz é trocar a linguagem de programação e complementar a API. No entanto, mantém a JVM.
O Groovy faz mais ou menos o mesmo. No entanto como a linguagem Groovy é praticamente um superconjunto de java, ele praticamente aumenta a linguagem de programação java ao invés de trocá-la.

O compilador da linguagem java gera os bytecodes para a máquina virtual. Mas, não há nada que impede que compiladores de outras linguagens façam o mesmo. É exatamente isso que ocorre com o JRuby e o Groovy.

O fato de Groovy ser um superconjunto (ou quase isso, não tenho certeza) da linguagem java, você pode pegar um programa java e compilá-lo com groovy. Porém nem sempre é possível o contrário.
Na questão dos bytecodes a interoperabilidade é maior, você pode utilizar .class gerados pelo Groovy no classpath ao compilar java, e vice-versa. Com JRuby ocorre mais ou menos o mesmo.

Observação: Marcio Duran, edita aí este título porque ele é muito longo. quando o GUJ coloca o "Re: " na frente dele ao responder, ele dá um erro porque fica grande demais.

:arrow: Grovvy ou JRuby Compartilhar recursos ou até ser subconjunto da Plataforma é entendível [b]mas não é isso que justifica java como sendo Plataforma[/b] pois senão o Core Java não existiria ou não faria sentido de ser e suas arquitetura J2EE/JEE pois tem especificações diferentes, é o mesmo que eu dissesse que Rails é Plataforma Java, o que não é verdade, “Rails tem sim interoperabilidade com a Plataforma JAVA por vias do JRuby”

a frase correta seria “jruby roda na plataforma java”, que é a JVM e as APIs (mas nesse caso nao a linguagem)

• Essa afirmação me confundiu !!!, no blog do SergioTaborda.

:arrow: Java tem a vantagem se ser simultaneamente um plataforma e uma linguagem de programação. Porque é uma plataforma ela suporta outras linguagens ( como Groovy ou JRuby).

Concordo com você Sergio Lopes,

:arrow: Isso mesmo, “nesse caso não a linguagem Java” por que isso é da Plataforma JAVA pois tem sua especificação propria, não me lembro a Java Community Presss escrever JRS ( http://jcp.org/en/jsr/all) para Groovy ou Ruby.

É realmente. Você está certo.
Normalmente essas linguagens são interpretadas, e não compiladas. Logo, raramente você verá um .class gerado por elas. O que ocorre é ter um interpretador rodando na JVM.

É realmente. Você está certo.
Normalmente essas linguagens são interpretadas, e não compiladas. Logo, raramente você verá um .class gerado por elas. O que ocorre é ter um interpretador rodando na JVM.

Um .class é apenas a persistencia do bytecode em arquivo. O bytecode é que realmente importa. JRuby não gera .class mas groovy pode gerar.

Sendo que o bytecode é o codigo nativo de uma JVM a linguagem java é compilada para a sua máquina alvo. ( o fato da máquina ser construida em cima de outra máquina e por isso ter que compilar para um novo codigo nativo é um detalhes da implementação atual da JVM padrão que usamos nos OS. Veja o SPOT ou o JavaCard por exemplo que tem uma JVM directamente em cima do silicio e portanto não precisa mudar nenhum bytecode para outro codigo nativo)
Linguagens que produzem bytecode são linguagems que compilam para JVM. Mesmo que essa compilação seja on-the-fly e apenas na memoria (i.e. no classloader). O Groovy é assim.
Outras linguagens desenvolvem máquinas virtuais em cima do java. Estas linguagens duplamente virtuais não compilam o codigo original para bytecode. JRuby por exemplo é uma destas. JRuby é na realidade uma VM em cima da JVM. Os objetos ruby são transformatos em objetos Java como um série de adendos injetados via bytecode manipulation em runtime. Isto é uma abordagem diferente do groovy.

Ou seja, se vc interceptar o classloader do groovy vc ve bytecode que poderia ter sido criado de qualquer outra forma. No JRuby vc não vc isso. A integração é diferente.

• Essa afirmação me confundiu !!!, no blog do SergioTaborda.

:arrow: Java tem a vantagem se ser simultaneamente um plataforma e uma linguagem de programação. Porque é uma plataforma ela suporta outras linguagens ( como Groovy ou JRuby).

Não entendo qual é a sua duvida. a palavra “Java” é o nome de uma tecnologia, uma plataforma.
Ao mesmo tempo é o nome de uma linaguagem (Java Programming Language - JPL)
A plataforma é formada pela especificação de uma máquina virtual (Java Virtual Machine - JVM)
Além disso existem as especificações de API padrão chamadas de edições : Java Standard Edition, Java Entreprise Edition e Java Micro Edition cada uma com ramificações e sub especificações.

Repare que tudo começa com a palavra “Java” porque tudo faz parte da mesma plataforma.

O que eu quis dizer na frase é que ha espaço na plataforma para criar outras linguagens que não a JPL que rodem na mesma JVM. Exemplos disso são o Groovy , o JavaFX ( e acho que Fortress e o Scala tb estão nesta categoria)
Além disso é possivel utilizar a JVM como máquina mãe sobre a qual criar outras VM : exemplos disso são o Jruby e o Jpyton (ouvi falar por ai em php rodando na jvm … mas não sei se não passa de rumores)

O .NET nasceu com a ideia de utilizar várias linguagens compilando para o seu “bytecode” ( comon language)
porque comercialmente precisava de força e historicamente precisava de dar suporte a outras linguagens (VB) logo, ele começou suportanto uma miriade de linguagem (C++, C#, J# , VB.NET ) e recentemente vem crescendo com F# e outros. Java começou com uma unica linguagem compilando para o seu bytecode. A mensagem era diferente. A ideia não era agradar a gregos e troianos e sim apresentar algo enxuto e simples.
Mas hoje, a plataforma java está anos-luz na frente da concorrencia ( o htostop é a VM mais evoluida do mercado melhor que qualquer outra e não para de melhorar) . Quem for esperto vai usar a JVM para construir a sua nova linguagems ou a CRL do .NET (não porque é evoluida, mas porque é uma forma de exnadir a palataforma). Qualquer coisa diferente disso é amadorismo. A menos é claro, que se lance uma nova linguagem com uma nova VM que seja melhor que a JVM.

No futuro a pessoa poderá escolher qual linguagem quer usar para escrever o seu codigo mas sempre contando que ele vai correr na jvm e poder usar as trocentas API que a plataforma já tem ( e tem cada vez mais)

Esta é a importancia dos novos bytecodes a serem incluidos no Java 7. Eles dão espaço para melhorias na plataforma e não directamente na linguagem. Isso permitirá que linguagens como scala e groovy possam usar os novos bytecodes para coisas como closures e tagtails sem que sejam necessários truques de bytecode manipulation ou artificios com interfaces e classes normais. Tudo isto independentemente se a linguagem java terá essas funcionalidades.

Java na verdade se refere a tres coisas:

Linguagem java

Plataforma Java

Ambiente de execução Java (JRE)

Sim. Existe a plataforma Java.

"

sergiotaborda:

Não entendo qual é a sua duvida. a palavra “Java” é o nome de uma tecnologia, uma plataforma.

:arrow:JRuby acessa parte de um conjunto da API da plataforma Java,Scripting Engines and Scripting Applications JRuby Scripting Engine Setup

Fonte :arrow: http://java.sun.com/developer/technicalArticles/scripting/jruby/#js

At runtime, the JSR 223 Scripting APIs must locate the appropriate script engine for the scripting language you want to use. The script engine interprets and executes the script. You can get the current JSR 223 third-party script engines from the Scripting Project on java.net by downloading the jsr223-engines.tar.gz or the jsr223-engines file and expanding it somewhere on your system, for example, in the scriptengines directory

Marcio Duran:

:arrow:JRuby acessa parte de um conjunto da API da plataforma Java,Scripting Engines and Scripting Applications JRuby Scripting Engine Setup

É o contrário. A API de Scripting é quem acessa e fornece a engine para as linguagens.

Se vc se refere a máquina hipotética (máquina virtual(processador)). è sim plataforma. A linguagem da máquina virtual também se chama java.

sergiotaborda:

Um .class é apenas a persistencia do bytecode em arquivo. O bytecode é que realmente importa. JRuby não gera .class mas groovy pode gerar.

…

Ou seja, se vc interceptar o classloader do groovy vc ve bytecode que poderia ter sido criado de qualquer outra forma. No JRuby vc não vc isso. A integração é diferente.

JRuby pode ser compilado pra bytecode antes (usando o jrubyc, que é o pré-compilador pra bytecode Java) ou você também pode deixar pra que o código seja transformado em bytecode em tempo de execução. Assim como Java, o código jruby sempre roda em modo híbrido, com pedaços interpretados e pedaços compilados.

rcarneiro:

É o contrário. A API de Scripting é quem acessa e fornece a engine para as linguagens.

"Não é o que diz o exemplo abaixo"

FONTE
:arrow: http://www.javaworld.com/javaworld/jw-11-2007/jw-11-jsr223.html?page=2

Most scripting engines also allow you to bind host variables of the Java environment to your script, as well as invoking specific scripting functions. Please note that some scripting engines require additional settings to use extended features. For example system properties like jruby.home and jruby.lib have to be set within JRuby to call gems.

// run a Ruby scripting  (JRuby V1.1b1)
Ruby runtime = Ruby.getDefaultInstance();
runtime.executeScript(scripting, filename);

// run a Groovy scripting (Groovy V1.1)
GroovyShell gs = new GroovyShell();
gs.evaluate(scripting);

// run a Python scripting (jython V2.2)
PythonInterpreter interp = new PythonInterpreter();
interp.exec(scripting)