JRuby es una implementación del lenguaje de programación Ruby sobre la máquina virtual Java , escrito principalmente en Java . Es un software libre publicado bajo una licencia tripartita EPL / GPL / LGPL . JRuby está estrechamente integrado con Java para permitir la incorporación del intérprete en cualquier aplicación Java con acceso bidireccional completo entre el código Java y el código Ruby (similar a Jython para el lenguaje Python).
Los desarrolladores principales de JRuby son Charles Oliver Nutter y Thomas Enebo, y muchos de los colaboradores actuales y pasados incluyen a Ola Bini y Nick Sieger. En septiembre de 2006, Sun Microsystems contrató a Enebo y Nutter para trabajar en JRuby a tiempo completo. [2] En junio de 2007, ThoughtWorks contrató a Ola Bini para trabajar en Ruby y JRuby. [3]
En julio de 2009, los desarrolladores de JRuby dejaron Sun para continuar el desarrollo de JRuby en Engine Yard . [4] En mayo de 2012, Nutter y Enebo dejaron Engine Yard para trabajar en JRuby en Red Hat . [5]
JRuby fue creado originalmente por Jan Arne Petersen en 2001. En ese momento y durante varios años, el código era un puerto directo del código C de Ruby 1.6 . Con el lanzamiento de Ruby 1.8.6, se inició un esfuerzo para actualizar JRuby a las características y la semántica de 1.8.6. Desde 2001, varios colaboradores han colaborado en el proyecto, lo que ha dado lugar al [actualizar]equipo central actual (2012) de unos seis miembros.
JRuby 1.1 agregó los modos de compilación Just-in-time y Ahead-of-time a JRuby y ya era más rápido en la mayoría de los casos que la implementación de referencia Ruby 1.8.7 vigente en ese momento. [6]
Los paquetes JRuby están disponibles para la mayoría de las plataformas; Fedora 9 fue uno de los primeros en incluirlo como paquete estándar en JRuby 1.1.1. [7] [8]
En julio de 2009, los desarrolladores principales de JRuby en Sun Microsystems, Charles Oliver Nutter, Thomas Enebo y Nick Sieger, se unieron a Engine Yard para continuar con el desarrollo de JRuby. [4] [9] En mayo de 2012, Nutter y Enebo dejaron Engine Yard para trabajar en JRuby en Red Hat . [5]
JRuby ha admitido la compatibilidad con las versiones 1.6 a 1.9.3 de Ruby MRI . JRuby 1.0 admitía Ruby 1.8.6, y JRuby 1.4.0 actualizó esa compatibilidad con Ruby 1.8.7. JRuby 1.6.0 agregó compatibilidad simultánea con Ruby 1.9.2, y JRuby 1.7.0 convirtió a Ruby 1.9.3 en el modo de ejecución predeterminado (la compatibilidad con Ruby 1.8.7 está disponible mediante una bandera de línea de comandos). JRuby 9.0.0.0 agregó compatibilidad con Ruby 2.2.
La versión actual de JRuby (9.4.3.0) apunta a Ruby 3.1, aunque algunas características de 3.1 todavía están en desarrollo. [10]
JRuby ha sido capaz de ejecutar el framework web Ruby on Rails desde la versión 0.9 (mayo de 2006), [11] [12] con la capacidad de ejecutar RubyGems y WEBrick . Desde que Sun contrató a los dos desarrolladores principales, la compatibilidad y velocidad de Rails han mejorado enormemente. La versión 1.0 de JRuby pasó con éxito casi todos los casos de prueba de Rails. [13] Desde entonces, los desarrolladores han comenzado a utilizar JRuby para aplicaciones Rails en entornos de producción. [14]
El 27 de febrero de 2008, Sun Microsystems y la Universidad de Tokio anunciaron un proyecto de investigación conjunto para implementar una máquina virtual capaz de ejecutar más de una aplicación Ruby o JRuby en un intérprete. [15]
JSR 292 ( Compatibilidad con lenguajes tipados dinámicamente en la plataforma JavaTM ) [16] propone:
invokedynamic
instrucción a nivel de JVM, permitiendo la invocación de métodos usando verificación de tipo dinámica ,El proyecto de código abierto Multi Language Virtual Machine de Sun tiene como objetivo crear un prototipo de este JSR. [17] El primer prototipo funcional, desarrollado como un parche en OpenJDK , se anunció y se puso a disposición a fines de agosto de 2008. [18] [19]
El equipo de JRuby ha implementado la invocación dinámica en su código base. La invocación dinámica se entregó inicialmente con la versión 1.1.5 en una forma primitiva. [20] La versión 1.7.0 la habilitó de manera predeterminada en las compilaciones de Java 8. [21]
Esta tabla presenta solo las versiones que representan avances significativos en la historia de JRuby, además de las versiones que principalmente corrigieron errores y mejoraron el rendimiento. Las mejoras de rendimiento tampoco se muestran en la tabla siguiente, ya que cada versión generalmente ha traído consigo dichas mejoras.
Desde principios de 2006, el equipo central actual de JRuby se ha esforzado por hacer que JRuby fuera más que un simple port de C, para ofrecer un mejor rendimiento y facilitar la compilación final a bytecode de Java . Para lograr este fin, el equipo se fijó un objetivo ambicioso: poder ejecutar Ruby on Rails sin modificaciones utilizando JRuby. En el proceso de alcanzar este objetivo, el conjunto de pruebas de JRuby se expandió hasta tal punto que el equipo ganó confianza en la "corrección" de JRuby. Como resultado, hacia finales de 2006 y principios de 2007, comenzaron a realizar rediseños y refactorizaciones mucho más complicados de los subsistemas centrales de JRuby.
JRuby está diseñado para funcionar como una máquina virtual de modo mixto para Ruby, donde el código puede ser interpretado directamente, compilado justo a tiempo en tiempo de ejecución a bytecode Java, o compilado con anticipación a bytecode Java antes de la ejecución. Hasta octubre de 2007, solo el modo interpretado admitía todas las construcciones de Ruby, pero desde la versión 1.1 está disponible un compilador AOT/JIT completo. [22] El diseño del compilador permite que el código interpretado y compilado se ejecuten en paralelo, así como la descompilación para reoptimizar y generar el bytecode generado como archivos de clase Java.
JRuby tiene soporte integrado para Rails, RSpec, Rake y RubyGems. Incorpora un subsistema FFI para permitir el uso de bibliotecas C incluidas como gemas. También permite ejecutar Interactive Ruby Shell (irb) como lo hace Ruby MRI.
El Netbeans Ruby Pack , disponible en NetBeans 6, permite el desarrollo de IDE con Ruby y JRuby, así como Ruby on Rails para las dos implementaciones de Ruby. [42] [43] Ya no está incluido en NetBeans 7.0 y versiones posteriores.
JRuby es similar al intérprete estándar de Ruby, excepto que está escrito en Java . JRuby presenta algunos de los mismos conceptos, incluida la programación orientada a objetos y el tipado dinámico de Ruby. La diferencia clave es que JRuby está estrechamente integrado con Java y se puede llamar directamente desde programas Java. [44] Java tiene una base importante en el desarrollo de aplicaciones web.
Una característica poderosa de JRuby es su capacidad de invocar las clases de la plataforma Java . Para ello, primero se debe cargar el soporte de Java de JRuby, llamando a "require 'java'". El siguiente ejemplo crea un JFrame de Java con un JLabel:
requiere 'java' frame = javax . swing . JFrame . new frame . getContentPane . add javax . swing . JLabel . new ( '¡Hola, mundo!' ) frame . setDefaultCloseOperation javax . swing . JFrame :: EXIT_ON_CLOSE frame . pack frame . set_visible true
JRuby también permite al usuario llamar al código Java utilizando el método de denominación de guión bajo más parecido al de Ruby y hacer referencia a las propiedades de JavaBean como atributos: [ dudoso – discutir ]
frame . content_pane . agregar etiqueta frame . visible = true
JRuby se puede llamar con la misma facilidad desde Java, utilizando el marco de trabajo JSR 223 [45] Scripting para Java 6 o Apache Bean Scripting .
//Ejemplo que utiliza JSR 233 Scripting para Java 6 ScriptEngineManager mgr = new ScriptEngineManager (); ScriptEngine rbEngine = mgr . getEngineByExtension ( "rb" ); try { rbEngine . eval ( "puts 'Hello World!'" ); } catch ( ScriptException ex ) { ex . printStackTrace (); }
Según algunos puntos de referencia, JRuby es más rápido que las alternativas. Dado que las implementaciones varían en la cantidad de código que se carga antes de la ejecución, los diferentes métodos de medición de la velocidad pueden dar lugar a interpretaciones sesgadas de las ventajas de rendimiento. El tiempo que tarda una máquina virtual Java en cargarse suele excluirse de los tiempos de ejecución al calcular los puntos de referencia.
JRuby tiene la importante ventaja arquitectónica de poder aprovechar los subprocesos de JVM sin estar restringido por un bloqueo de intérprete global (de manera similar a Rubinius ), logrando así un paralelismo total dentro de un proceso, algo que Ruby MRI no puede lograr a pesar de aprovechar los subprocesos del sistema operativo.
En una aplicación de servidor web Mongrel real probada en 2007, el rendimiento de JRuby es mejor que el de Ruby MRI 1.8, después de haber creado una instancia de la máquina virtual Java. [46]
En una evaluación comparativa de 2007 sobre implementaciones de Ruby, JRuby fue más rápido que Ruby MRI 1.8 en algunas pruebas, pero YARV superó a ambos. [47]
A partir de abril de 2014, en The Computer Language Benchmarks Game , JRuby 1.7.4 generalmente tiene el mismo rendimiento que Ruby MRI 2.1.0, pero utiliza más memoria. [48] [49]
enviará con JRuby 1.1.5 (aunque obviamente se deshabilitará en las JVM sin InvokeDynamic).