Java 6 permitirá misturar scripts com código Java

[Luca]

Olá

A JSR 223 é a base para possibilitar a mistura de JavaScript dentro do código Java. A API permitirá usuários mais avançados incluir os motores de script de sua escolha. Além disso, o Web Scripting Framework permitirá scripts para gerar conteúdo Web de dentro de qualquer Servlet container. Aliás, a especificação foi feita mais com intuito de ser usada com servlets.

Vejam uma introdução a JSR 223 em Build your own scripting language for Java

[]s
Luca

[juzepeleteiro]

Já é possível hoje, nao no mesmo arquivo fonte, com Groovy e JavaScript. (Além de outras…)

[Luca]

Olá

Pode mostrar um exemplo? De novo repito, se já existe porque muitos passaram anos discutindo e depois ainda criam uma API para tal?

No Java 6 haverá um método para pegar o MAC Address. Eu já faço isto usando somente Java desde o Java 1.2. Mas nem por isto se pode dizer que já existia no Java. Muitas das novidades do Java 6 no âmbitos das Collections como Deques por exemplo tem muita gente que já faz na mão há muitos anos. Por aí vai…

[]s
Luca

[Grinvon]

Pelo visto Luca, Java tende a se tornar uma linguagem mais dinâmica, falo em “dinâmica” no ambito de produtividade e facilidade, resultando assim em melhores trabalhos!

[Luca]

Olá

Package javax.script

The scripting API consists of interfaces and classes that define Java TM Scripting Engines and provides a framework for their use in Java applications.

See:
Description

Interface Summary

Bindings - A mapping of key/value pairs, all of whose keys are Strings.

Compilable - The optional interface implemented by ScriptEngines whose methods compile scripts to a form that can be executed repeatedly without recompilation.

Invocable - The optional interface implemented by ScriptEngines whose methods allow the invocation of procedures in scripts that have previously been executed.

ScriptContext - The interface whose implementing classes are used to connect Script Engines with objects, such as scoped Bindings, in hosting applications.

ScriptEngine - ScriptEngine is the fundamental interface whose methods must be fully functional in every implementation of this specification.

ScriptEngineFactory - ScriptEngineFactory is used to describe and instantiate ScriptEngines.

Class Summary

AbstractScriptEngine - Provides a standard implementation for several of the variants of the eval method.

CompiledScript - Extended by classes that store results of compilations.

ScriptEngineManager - The ScriptEngineManager implements a discovery and instantiation mechanism for ScriptEngine classes and also maintains a collection of key/value pairs storing state shared by all engines created by the Manager.

SimpleBindings - A simple implementation of Bindings backed by a HashMap or some other specified Map.

SimpleScriptContext - Simple implementation of ScriptContext.

Exception Summary

ScriptException - The generic Exception class for the Scripting APIs.

Package javax.script Description

The scripting API consists of interfaces and classes that define Java TM Scripting Engines and provides a framework for their use in Java applications. This API is intended for use by application programmers who wish to execute programs written in scripting languages in their Java applications. The scripting language programs are usually provided by the end-users of the applications.

The main areas of functionality of javax.script package include

1.  Script execution: Scripts are streams of characters used as sources for programs executed by script engines. Script execution uses eval methods of ScriptEngine and methods of the Invocable interface.
   

2.  Binding: This facility allows Java objects to be exposed to script programs as named variables. Bindings and ScriptContext classes are used for this purpose.
   

3.  Compilation: This functionality allows the intermediate code generated by the front-end of a script engine to be stored and executed repeatedly. This benefits applications that execute the same script multiple times. These applications can gain efficiency since the engines' front-ends only need to execute once per script rather than once per script execution. Note that this functionality is optional and script engines may choose not to implement it. Callers need to check for availability of the Compilable interface using an instanceof check.
   

4.  Invocation: This functionality allows the reuse of intermediate code generated by a script engine's front-end. Whereas Compilation allows entire scripts represented by intermediate code to be re-executed, Invocation functionality allows individual procedures/methods in the scripts to be re-executed. As in the case with compilation, not all script engines are required to provide this facility. Caller has to check for Invocable availability.
   

5.  Script engine discovery and Metadata: Applications written to the Scripting API might have specific requirements on script engines. Some may require a specific scripting language and/or version while others may require a specific implementation engine and/or version. Script engines are packaged in a specified way so that engines can be discovered at runtime and queried for attributes. The Engine discovery mechanism is based on the Service discovery mechanism described in the Jar File Specification. Script engine implementing classes are packaged in jar files that include a text resource named META-INF/services/javax.script.ScriptEngineFactory. This resource must include a line for each ScriptEngineFactory that is packaged in the jar file. ScriptEngineManager includes getEngineFactories method to get all ScriptEngineFactory instances discovered using this mechanism. ScriptEngineFactory has methods to query attributes about script engine.
   

Since:
1.6

[]s
Luca

[Fabricio_Cozer_Marti]

é algo semelhante ao GWT ?

[pcalcado]

É possível misturar Groovy ou outra linguagem em Java sim, a JSR apenas padroniza a forma como as linguagens se integram ao Java.

[Luca]

olá

É possível misturar Groovy ou outra linguagem em Java sim, a JSR apenas padroniza a forma como as linguagens se integram ao Java.

Com qualquer linguagem é possível fazer qualquer coisa. O que não for nativo em Java se pode fazer em Assembler ou C e chamar via JNI.

Mas este tópico é sobre novidades do Java 6. Não é sobre tudo que já existe pronto dentro do conhecimento humano.

[]s
Luca

[pcalcado]

Não entendi seu ponto, Luca. Fugi do escopo do tópico?

O que estamos comentando aqui é que o scripting em Java está sendo padronizado e acho que todos concordamos que isso é uma coisa boa na maioria dos casos. O que eu e o Peleteiro (creio) tentamos falar é que isto já era possível, do contrário pessoas que usam Java 1.4 vão ficar esperando Java 6 pra usar este tipo de recurso.

[Luca]

Olá

Phillip, uso Java desde a versão 1.02 e já vi muita coisa ser acrescentada ao Java. Acho que as linguagens evoluem mais com a evolução da API pois em termos de linguagem propriamente dita pouco pode ser feito.

Já participei de projetos que em que foi preciso perder um tempão descobrindo modos alternativos para fazer determinadas coisas. O Java 6 vem com várias novidades na API justamente para não obrigar a comunidade desenvolvedora ficar na dependência de soluções mirabolantes do gênio de plantão, presente apenas durante o projeto, que geralmente deixa aquele legado “genial” mal documentado. Estando disponível na linguagem é mais fácil convencer ao lider do projeto que é viável adotar determinado caminho. Dificilmente eu aprovaria a incorporção de APIs com comunidade frágil como o Janino em algum projeto.

Sempre que aparece uma nova versão do Java eu procuro saber o que ela tem de novidade e o que foi solucionado. Às vezes o modo usado pela nova versão Java não chega a me seduzir como foi o caso da API de logging surgida no Java 1.4. Nestes casos não deixo de usar o que há disponível por aí que me parece mais fácil ou mais confiável.

Meu intuito nestes posts de apontar novidades é o de apenas dizer que existe. Se há outras alternativas melhores, cabe ao quem acha isto apontar como pode ser feito.

Na minha opinião, o erro do José Peleteiro e talvez o seu também foi dizer que há outros meios mas não mostrar como.

[]s
Luca

[pcalcado]

Sei não, acho que você tomou os posts como uma crítica a divulgação da notícia ou ao Java 6 em si, de minha parte foi apenas um comentário, eu sequer posso saber se A ou B é melhor porque não tive contato direto com o scripting do mustang ainda.

De qualquer forma, para saber como integrar Groovy com Java basta olhar o site a linguagem:

http://docs.codehaus.org/display/GROOVY/Bean+Scripting+Framework

–

Java não está se tornando uma linguagem mais dinâmica, está se tornando uma plataforma mais dinâmica. A linguagem Java continua a mesma.

[Thiagosc]

Já participei de projetos que em que foi preciso perder um tempão descobrindo modos alternativos para fazer determinadas coisas. O Java 6 vem com várias novidades na API justamente para não obrigar a comunidade desenvolvedora ficar na dependência de soluções mirabolantes do gênio de plantão, presente apenas durante o projeto, que geralmente deixa aquele legado “genial” mal documentado. Estando disponível na linguagem é mais fácil convencer ao lider do projeto que é viável adotar determinado caminho. Dificilmente eu aprovaria a incorporção de APIs com comunidade frágil como o Janino em algum projeto.

Sou obrigado a concordar. Eu também penso que é preferível manter a lista de dependências de APIs externas no mínimo, e verificar sempre se as mesmas são mantidas e são maduras o suficiente.

Imagina ter que gastar tempo que deveria ser usado para um cliente para consertar APIs de terceiros que não são mantidas. Com as APIs da JDK padrão dá mais confiança de que será mantida e que possui um nível mínimo de qualidade.