Pregunta

Veo aquí que hay una gran cantidad de lenguajes además de Java que se ejecutan en la JVM.Estoy un poco confundido acerca del concepto de otros lenguajes que se ejecutan en la JVM.Entonces:

¿Cuál es la ventaja de tener otros lenguajes para la JVM?

¿Qué se requiere (en términos de alto nivel) para escribir un lenguaje/compilador para la JVM?

¿Cómo se escribe/compila/ejecuta código en un lenguaje (que no sea Java) en la JVM?


EDITAR: Hubo 3 preguntas de seguimiento (originalmente comentarios) que fueron respondidas en la respuesta aceptada.Se reimprimen aquí para mayor legibilidad:

¿Cómo interactuaría una aplicación escrita, por ejemplo, en JPython, con una aplicación Java?

Además, ¿esa aplicación JPython puede utilizar alguna de las funciones/objetos JDK?

¿Y si fuera código Jaskell, el hecho de que sea un lenguaje funcional no lo haría incompatible con el JDK?

¿Fue útil?

Solución

Para abordar sus tres preguntas por separado:

¿Cuál es la ventaja de tener otros lenguajes para la JVM?

Hay dos factores aquí.(1) ¿Por qué tener un lenguaje distinto de Java para la JVM y (2) por qué ejecutar otro lenguaje en la JVM, en lugar de un tiempo de ejecución diferente?

  1. Otros idiomas pueden satisfacer otras necesidades.Por ejemplo, Java no tiene soporte integrado para cierres, una característica que suele resultar muy útil.
  2. Un lenguaje que se ejecuta en la JVM es compatible con un código de bytes con cualquier otro lenguaje que se ejecute en la JVM, lo que significa que el código escrito en un idioma puede interactuar con una biblioteca escrita en otro idioma.

¿Qué se requiere (en términos de alto nivel) para escribir un lenguaje/compilador para la JVM?

La JVM lee archivos de código de bytes (.class) para obtener las instrucciones que necesita para realizar.Por lo tanto, cualquier lenguaje que se ejecute en la JVM debe compilarse en un código de bytes que se adhiera al Especificación solar.Este proceso es similar a compilar en código nativo, excepto que en lugar de compilar en instrucciones entendidas por la CPU, el código se compila en instrucciones que son interpretadas por la JVM.

¿Cómo se escribe/compila/ejecuta código en un lenguaje (que no sea Java) en la JVM?

De forma muy parecida a como escribes/compilas/ejecutas código en Java.Para mojarse los pies, recomiendo mirar escala, que se ejecuta perfectamente en la JVM.

Respondiendo a sus preguntas de seguimiento:

¿Cómo interactuaría una aplicación escrita, por ejemplo, en JPython, con una aplicación Java?

Esto depende de la elección de la implementación de cerrar la brecha lingüística.En tu ejemplo, proyecto jython tiene una forma sencilla de hacer esto (mira aquí):

from java.net import URL
u = URL('http://jython.org')

Además, ¿esa aplicación JPython puede utilizar alguna de las funciones/objetos del JDK?

Sí, ver arriba.

¿Y si fuera código Jaskell, el hecho de que sea un lenguaje funcional no lo haría incompatible con el JDK?

No.Scala (enlace arriba), por ejemplo, implementa características funcionales manteniendo la compatibilidad con Java.Por ejemplo:

object Timer {
  def oncePerSecond(callback: () => unit) {
    while (true) { callback(); Thread sleep 1000 }
  }
  def timeFlies() {
    println("time flies like an arrow...")
  }
  def main(args: Array[String]) {
    oncePerSecond(timeFlies)
  }
}

Otros consejos

Necesita otros lenguajes en la JVM por la misma razón que necesita múltiples lenguajes de programación en general:Diferentes idiomas son mejores para resolver diferentes problemas...escritura estática vs.tipificación dinámica, estricta vs.perezoso ...Declarativo, Imperativo, Orientado a Objetos...etc.

En general, escribir un "compilador" para que otro lenguaje se ejecute en la JVM (o en .Net CLR) es esencialmente una cuestión de compilar ese lenguaje en un código de bytes de Java (o en el caso de .Net, IL) en lugar de en un ensamblador. /Lenguaje de máquina.

Dicho esto, muchos de los lenguajes adicionales que se escriben para JVM no están compilados, sino lenguajes de scripting interpretados...

Dando la vuelta a esto, considere que desea diseñar un nuevo lenguaje y desea que se ejecute en un tiempo de ejecución administrado con JIT y GC.Entonces considera que podrías:

(a) escriba su propio tiempo de ejecución administrado (VM) y aborde todo tipo de problemas técnicamente difíciles que sin duda provocarán muchos errores, mal rendimiento, subprocesos inadecuados y una gran cantidad de esfuerzo de portabilidad

o

(b) compilar su lenguaje en un código de bytes que pueda ejecutarse en la máquina virtual Java, que ya es bastante madura, rápida y compatible con varias plataformas (a veces con más de una opción de implementación del proveedor).

Dado que el código de bytes de JavaVM no está tan estrechamente vinculado al lenguaje Java como para restringir indebidamente el tipo de lenguaje que se puede implementar, ha sido un entorno de destino popular para los lenguajes que desean ejecutarse en una VM.

Java es un lenguaje de programación bastante detallado que se está quedando obsoleto muy rápidamente con todos los nuevos lenguajes/marcos sofisticados que han aparecido en los últimos 5 años.Para admitir toda la sintaxis sofisticada que la gente desea en un idioma Y preservar la compatibilidad con versiones anteriores, tiene más sentido agregar más idiomas al tiempo de ejecución.

Otro beneficio es que le permite ejecutar algunos marcos web escritos en Ruby o JRuby (también conocido como Rails) o Grails (esencialmente Groovy en Railys), etc.en una plataforma de alojamiento probada que probablemente ya esté en producción en muchas empresas, en lugar de tener que utilizar entornos de alojamiento Ruby que no son tan probados y probados.

Para compilar los otros lenguajes, simplemente está convirtiendo al código de bytes de Java.

Yo respondería: “porque Java apesta"Pero, de nuevo, tal vez eso sea muy obvio … ;-)

La ventaja de tener otros lenguajes para la JVM es la misma que la ventaja de tener otros lenguajes para la computadora en general:Si bien todos los lenguajes completos de Turing pueden técnicamente realizar las mismas tareas, algunos lenguajes facilitan algunas tareas que otros, mientras que otros facilitan otras.Dado que la JVM es algo que ya tenemos la capacidad de ejecutar en todas (bueno, casi todas) las computadoras, y muchas computadoras, de hecho, ya la tienen, podemos obtener el beneficio de "escribir una vez, ejecutar en cualquier lugar", pero sin requerir ese usa Java.

Escribir un lenguaje/compilador para JVM no es realmente diferente de escribir uno para una máquina real.La verdadera diferencia es que tienes que compilar en el código de bytes de la JVM en lugar del código ejecutable de la máquina, pero eso es realmente una diferencia menor en el gran esquema de las cosas.

Escribir código para un lenguaje distinto de Java en la JVM realmente no es diferente de escribir Java excepto, por supuesto, que usarás un lenguaje diferente.Compilarás usando el compilador que alguien escribe para él (nuevamente, no muy diferente de un compilador de C, fundamentalmente, y prácticamente no diferente de un compilador de Java), y terminarás siendo capaz de ejecutarlo simplemente como lo haría con el código Java, ya que una vez que está en código de bytes, la JVM no puede saber de qué idioma proviene.

Diferentes idiomas se adaptan a diferentes tareas.Si bien ciertos dominios problemáticos se ajustan perfectamente al lenguaje Java, algunos son mucho más fáciles de expresar en lenguajes alternativos.Además, para un usuario acostumbrado a Ruby, Python, etc., la capacidad de generar código de bytes de Java y aprovechar las clases JDK y el compilador JIT tiene beneficios obvios.

Respondiendo solo a tu segunda pregunta:

La JVM es solo una máquina abstracta y un modelo de ejecución.Por lo tanto, apuntarlo con un compilador es lo mismo que cualquier otra máquina y modelo de ejecución al que podría apuntar un compilador, ya sea implementado en hardware (x86, CELL, etc.) o software (parrot, .NET).La JVM es bastante simple, por lo que en realidad es un objetivo bastante fácil para los compiladores.Además, las implementaciones tienden a tener compiladores JIT bastante buenos (para lidiar con el pésimo código que produce javac), por lo que puedes obtener un buen rendimiento sin tener que preocuparte por muchas optimizaciones.

Se aplican un par de advertencias.En primer lugar, la JVM incorpora directamente el módulo de Java y el sistema de herencia, por lo que intentar hacer cualquier otra cosa (herencia múltiple, envío múltiple) probablemente sea complicado y requiera un código complicado.En segundo lugar, las JVM están optimizadas para manejar el tipo de código de bytes que produce javac.Producir un código de bytes que sea muy diferente de este probablemente llegue a rincones extraños del compilador JIT/JVM, lo que probablemente será ineficiente en el mejor de los casos (en el peor de los casos, puede bloquear la JVM o al menos dar excepciones falsas de VirtualMachineError).

Lo que puede hacer la JVM está definido por el código de bytes de la JVM (lo que se encuentra en los archivos .class) en lugar del idioma fuente.Por lo tanto, cambiar el lenguaje del código fuente de alto nivel no tendrá un impacto sustancial en la funcionalidad disponible.

En cuanto a lo que se requiere para escribir un compilador para JVM, todo lo que realmente necesita hacer es generar archivos de código de bytes/.class correctos.La forma de escribir/compilar código con un compilador alternativo depende del compilador en cuestión, pero una vez que el compilador genera archivos .class, ejecutarlos no es diferente a ejecutar los archivos .class generados por javac.

La ventaja para estos otros lenguajes es que obtienen un acceso relativamente fácil a muchas bibliotecas de Java.

La ventaja para la gente de Java varía según el idioma: cada uno tiene una historia que les cuenta a los programadores de Java lo que hacen mejor.Algunos enfatizarán cómo se pueden usar para agregar secuencias de comandos dinámicas a aplicaciones basadas en JVM, otros simplemente hablarán de cómo su lenguaje es más fácil de usar, tiene una mejor sintaxis, etc.

Lo que se requiere son las mismas cosas para escribir cualquier otro compilador de lenguaje:analizar un AST, luego transformarlo en instrucciones para la arquitectura de destino (código de bytes) y almacenarlo en el formato correcto (archivos .class).

Desde la perspectiva de los usuarios, simplemente escribe código y ejecuta los binarios del compilador, y salen archivos .class que puede mezclar con los que produce su compilador Java.

Los lenguajes .NET son más un espectáculo que una utilidad real.Cada lenguaje ha sido tan masacrado que todos son C# con una nueva cara.

Hay una variedad de razones para proporcionar lenguajes alternativos para Java VM:

  • La JVM es multiplataforma.Cualquier idioma portado a la JVM lo obtiene como un bono gratuito.
  • Existe bastante código heredado.Los motores anticuados como ColdFusion funcionan mejor y ofrecen a los clientes la capacidad de pasar lentamente sus aplicaciones de la solución heredada a la solución moderna.
  • Ciertas formas de secuencias de comandos se adaptan mejor al desarrollo rápido.JavaFX, por ejemplo, está diseñado teniendo en mente un rápido desarrollo gráfico.De esta forma compite con motores como DarkBasic.(El procesamiento es otro actor en este espacio).
  • Los entornos de secuencias de comandos pueden ofrecer control.Por ejemplo, es posible que una aplicación desee exponer un entorno similar a VBA al usuario sin exponer las API de Java subyacentes.El uso de un motor como Rhino puede proporcionar un entorno que admita codificación rápida y sucia en una zona de pruebas cuidadosamente controlada.
  • Los scripts interpretados significan que no es necesario volver a compilar nada.La no necesidad de recompilar se traduce en un entorno más dinámico.p.ej.A pesar del uso de Java por parte de OpenOffice como "lenguaje de secuencias de comandos", Java apesta para ese uso.El usuario tiene que pasar por todo tipo de giros de recompilación/recarga que son innecesarios en un entorno de scripting dinámico como Javascript.
  • Lo que me lleva a otro punto.Los motores de secuencias de comandos se pueden detener y recargar más fácilmente sin detener y recargar toda la JVM.Esto aumenta la utilidad del lenguaje de secuencias de comandos ya que el entorno se puede restablecer en cualquier momento.

Es mucho más fácil para un escritor de compiladores generar códigos de bytes JVM o CLR.Son una abstracción mucho más limpia y de mayor nivel que cualquier lenguaje de máquina.Debido a esto, es mucho más factible que nunca experimentar con la creación de nuevos lenguajes, porque todo lo que tiene que hacer es apuntar a una de estas arquitecturas de VM y tendrá un conjunto de herramientas y bibliotecas disponibles para su lenguaje.Permiten que los diseñadores de idiomas se centren más en el idioma que en toda la infraestructura de soporte necesaria.

Porque el proceso JSR hace que Java esté cada vez más muerto: http://www.infoq.com/news/2009/01/java7-updated

Es una pena que incluso adiciones esenciales y conocidas desde hace mucho tiempo como los cierres no se agreguen solo porque los miembros no pueden ponerse de acuerdo sobre una implementación.

Java ha acumulado una enorme base de usuarios en siete versiones principales (de 1.0 a 1.6).Su capacidad de evolucionar está limitada por la necesidad de preservar la compatibilidad con versiones anteriores de los incontables millones de líneas de código Java que se ejecutan en producción.

Esto es un problema porque Java necesita evolucionar para:

  • competir con lenguajes de programación más nuevos que han aprendido de los éxitos y fracasos de Java.
  • incorporar nuevos avances en el diseño de lenguajes de programación.
  • permitir a los usuarios aprovechar al máximo los avances en hardware, p.Procesadores multinúcleo.
  • corregir algunas ideas de vanguardia que introdujeron problemas inesperados (p. ej.excepciones marcadas, genéricos).

El requisito de compatibilidad con versiones anteriores es una barrera para seguir siendo competitivo.

Si compara Java con C#, Java tiene la ventaja en bibliotecas y marcos maduros y listos para producción, y una desventaja en términos de características del lenguaje y tasa de aumento en la participación de mercado.Esto es lo que se esperaría al comparar dos lenguajes exitosos separados por una generación.

Cualquier lenguaje nuevo tiene las mismas ventajas y desventajas que C# tiene en comparación con Java en un grado extremo.Una forma de maximizar la ventaja en términos de características del lenguaje y minimizar la desventaja en términos de bibliotecas y marcos maduros es crear el lenguaje para una máquina virtual existente y hacerlo interoperable con el código escrito para esa máquina virtual.Ésta es la razón del modesto éxito de Groovy y Clojure;y el entusiasmo en torno a Scala.Sin la JVM, estos lenguajes sólo podrían haber ocupado un nicho pequeño en un segmento de mercado muy especializado, mientras que con la JVM ocupan un nicho significativo en la corriente principal.

Lo hacen para mantenerse al día con .Net..Net permite C#, VB, J# (anteriormente), F#, Python, Ruby (próximamente) y c++.Probablemente me falta alguno.Probablemente el más importante sea Python, para la gente que realiza scripts.

Hasta cierto punto, es probable que se trate de una "carrera armamentista" contra .NET CLR.

Pero creo que también hay razones genuinas para introducir nuevos lenguajes en la JVM, particularmente cuando se ejecutarán "en paralelo", puedes usar el lenguaje correcto para el trabajo correcto, un lenguaje de script como Groovy puede ser exactamente lo que necesitas para la presentación de su página, mientras que el antiguo Java normal es mejor para su lógica empresarial.

Voy a dejar a alguien más calificado para que hable sobre lo que se requiere para escribir un nuevo lenguaje/compilador.

En cuanto a cómo escribir código, ¡lo haces en notepad/vi como de costumbre!(o utilice una herramienta de desarrollo que admita el lenguaje si desea hacerlo de la manera más sencilla). La compilación requerirá un compilador especial para el lenguaje que lo interpretará y compilará en código de bytes.

Dado que Java también produce técnicamente código de bytes, no es necesario hacer nada especial para ejecutarlo.

La razón es que la plataforma JVM ofrece muchas ventajas.

  • Número gigante de bibliotecas
  • Grado más amplio de implementaciones de plataforma
  • Marcos maduros
  • Código heredado que ya es parte de su infraestructura

Los lenguajes que Sun intenta admitir con su especificación de secuencias de comandos (p. ej.Python, Ruby) están en auge en gran medida debido a las mejoras percibidas en su productividad.Ejecutar Jython le permite, en teoría, ser más productivo y aprovechar las capacidades de Pitón para resolver un problema más adecuado para Python, pero aún así poder integrarlo, a nivel de tiempo de ejecución, con su código base existente.Las implementaciones clásicas de Pitón y Rubí efectuar la misma habilidad para C bibliotecas.

Además, suele ser más fácil expresar algunas cosas en un lenguaje dinámico que en Java.Si este es el caso, puedes ir por el otro lado;consumir Pitón/Rubí bibliotecas de Java.

Hay un impacto en el rendimiento, pero muchos están dispuestos a aceptarlo a cambio de un código base menos detallado y más claro.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top