¿Microsoft supera a Java en soporte de lenguaje dinámico?
Autor Werner Schuster Traductor Li Xin
Cuando NET se lanzó por primera vez en /, la comunidad Java pensó que era solo un clon de Java en términos de lenguaje y biblioteca estándar. Obtenga esta sensación al comparar los códigos de ejemplo simples de los dos. Sin embargo, Microsoft se ha beneficiado enormemente de sus muchos años de experiencia en Java y ha resuelto con éxito algunos problemas de los que Sun recién ahora es consciente. La comunidad de Java también está empezando a pensar. que NET y CLR se están desarrollando más rápido que Java
Neil Bartlett dijo
Creo que es muy obvio que la velocidad de innovación de Microsoft en CLR es más rápida. Por ejemplo, LINQ es una novedad extremadamente poderosa. característica (agregando que se basa en las mónadas del lenguaje Haskell). Los genéricos también son más antiguos y tienen mejor soporte en C# que en Java (el estilo genérico de ambos está influenciado por los tipos polimórficos de Haskell) Inspirado en [Clases de tipos polimórficos]... ¡Hmm! ) CLR proporciona mejor soporte multilingüe que JVM y ahora tiene DLR, y se necesitarán otros dos años para que aparezcan productos comparables en JVM
Otros ejemplos incluyen
Modularidad y control de versiones. NET utiliza Assembly (una colección de clases) como unidad de implementación básica para resolver este problema. Assembly incluye metadatos como información de versión. Por el contrario, los archivos Jar de Java carecen de metadatos como información de versión. Esta falla traerá muchos problemas a proyectos grandes que cargan muchas bibliotecas de clases en crecimiento. Actualmente, OSGi ha proporcionado una solución y Sun también está ocupado agregando soluciones similares a Java agregando funciones. como el autoboxing genérico (AutoBoxing), los tipos enumerados (tipos enumerados) y las anotaciones en el lenguaje Java. NET C# ahora proporciona soporte para expresiones anónimas. Esta característica es uno de los componentes básicos de la tecnología LINQ y puede considerarse un lenguaje de consulta de tipo estático. para una variedad de fuentes de datos diferentes. Las fuentes de datos mencionadas aquí pueden ser XML, una base de datos relacional o incluso cualquier gráfico de objetos. Al mismo tiempo, la comunidad Java todavía está debatiendo cuestiones triviales. idioma, como las propiedades (Propiedades) admitidas por el idioma y cuál de los cuatro métodos anónimos (cierres) se debe utilizar Soporte de idioma incorporado
Con el lanzamiento de DLR, Microsoft ha vuelto a tomar. Esta vez, una vez más ha comenzado a liderar el campo de Java en el campo del soporte CLR para lenguajes dinámicos o lenguajes de script. Actualmente, no existe una medida correspondiente. El proyecto Mono es una implementación NET muy pura. de Icaza, su iniciador, resume las características de DLR de la siguiente manera
·Un sistema de tipos compartidos para lenguajes dinámicos·Un AST compartido que puede ser utilizado por idiomas Utilizado por desarrolladores para crear nuevos lenguajes dinámicos · Ayudante /clases de utilidad para desarrolladores de compiladores · Una interfaz de host común que le permite incorporar interfaces de lenguaje de scripting comunes en sus programas y permite a los desarrolladores usar un tipo de lenguaje dinámico Sistema de extensión de lenguaje·Soporte de consola DLR incluso proporciona una interfaz de consola simple para programación interactiva
***El sistema de tipos compartidos permite la interacción entre lenguajes dinámicos. Jim Hugunin revela el mecanismo detrás de esto y demuestra cómo Java maneja esta situación y cómo el DLR es único. Después de todo, él entiende la diferencia. desarrolló el proyecto Jython, una implementación de Python basada en JVM. Recientemente cambió a la plataforma Microsoft y desarrolló IronPython (implementación de Python basada en CLR)
Jim Hugunin explica uno de los problemas de esta manera
El uso de Wrapper (wrapper) también puede tener problemas más profundos. Uno de los desafíos es determinar el objeto que se debe pasar, por ejemplo, si Python tiene un PyString. objeto Y cuando llama a un método C# que requiere un objeto, ¿debería pasar un objeto PyString o debería descomprimirlo en un objeto String? Nunca hay una respuesta perfecta a estos problemas de tipos tan esquivos. Peor aún, existen algunos problemas muy complicados causados por intentar envolver o descomprimir objetos sin el conocimiento del programador, lo que resulta en la pérdida de la identidad del objeto.
Estos Sin duda, también existen problemas en el campo Java, como la forma en que JRuby maneja las transferencias de cadenas entre el código Java y Ruby
·Las cadenas Java pasadas al código Ruby se codificarán en UTF. Esto implica que debes trabajar con bytes UTF. [] en el código que recibe parámetros. También se supone que las cadenas Ruby son UTF cuando se pasan a Java. El resultado devuelto de la llamada del lado Java debe ajustarse a esta suposición
El campo Java sí. No implementará las cosas que mencionamos anteriormente, excepto la interfaz de alojamiento. Se implementará en Java de acuerdo con la especificación JSR. La interfaz de alojamiento (en Java) es solo un marco. El marco proporciona la capacidad de agregar nuevos tiempos de ejecución de lenguaje y de forma estándar. para inicializarlo y acceder a él
Jim Hugunin revela además cómo se maneja el envío de métodos dinámicos. Este proceso utiliza métodos de extensión (métodos de extensión) y otros sistemas CLR existentes. Único en Java. Un esfuerzo comparable es el JSR. Lo que hay que hacer es agregar un nuevo código de bytes invokedynamic. La idea vino de Gilad Bracha. Dejó Sun poco después de crear JSR y ahora no es optimista al respecto.
JSR es un esfuerzo que inicié para resolver estos problemas. Espero que pueda continuar en mi ausencia, pero todavía faltan varios años para que este proyecto produzca resultados (si es posible). Francamente, es más difícil agregar soporte para estas características. la JVM y luego hacer que Strongtalk sea más estable
Tenga en cuenta que Strongtalk es una implementación de Smalltalk y su VM es la tecnología HotSpot. La base de la tecnología HotSpot se ha lanzado con la JVM de Sun durante mucho tiempo
Danny Coward, el líder de especificaciones de JSR, tiene más confianza en la mejora del rendimiento.
Los creadores de motores de lenguaje dinámico están ocupados convirtiendo el código Ruby en código de bytes de Java cuando el motor JRuby intenta convertir llamadas a métodos en código de bytes. , debe crear una interfaz sintética para representar el tipo de retorno. Este no es un desarrollador. La interfaz creada es creada por el motor JRuby para que el motor pueda manejar la llamada al método y convertirla en código de bytes y ese es el tipo de retorno; lo mismo es. verdadero para parámetros de métodos y excepciones
JSR elimina la necesidad de tales interfaces sintéticas. Hoy en día, los intérpretes de lenguaje dinámico deben generar el código de bytes de las llamadas a métodos incluso cuando interpretan y ejecutan, digamos, un fragmento de código Ruby mañana con JSR. los intérpretes usarán la versión invokedynamic Hará que las implementaciones del motor de lenguaje dinámico sean mucho más simples porque muchos motores hoy en día se molestan en crear nuevas interfaces sintéticas y llevar mucha contabilidad cuando se llama a un método en siete u ocho lugares diferentes y el motor tiene que estar allí. en todos ellos reutilización local de esas interfaces sintéticas
Vale la pena señalar que estas mejoras se escribirán en la especificación JVM, lo que significa que estas características serán compatibles con el soporte integrado (codificadas) y. No será fácil en el futuro. El beneficio de actualizar el enfoque basado en bibliotecas es que podrá adoptarse rápidamente cuando surjan mejores formas de manejar estos sistemas.
El enfoque de la JVM seguirá siendo el mismo durante mucho tiempo porque la JVM a menudo tiene una vida útil prolongada (como referencia, muchas empresas todavía utilizan Java) y la JVM realmente adoptará este código de bytes y lo mejorará. ¿Qué tan rápidas son las llamadas a métodos dinámicos? ? Esto también está por verse.
Otro problema es el soporte oficial y el reconocimiento de los lenguajes basados en JVM. Actualmente, JRuby tiene dos desarrolladores que reciben salarios de Sun. Uno de ellos es Charles O Nutter, que se ha unido. Está por verse si estos esfuerzos despegarán entre las comunidades Jython y Groovy. Microsoft tiene una cierta ventaja en este sentido, considerando que Microsoft tiene un equipo de desarrollo muy unido que trabaja en varios lenguajes dinámicos como IronPython, IronRuby, JavaScript, y soporte dinámico de VB después de todo, DLR es un producto en el que diferentes equipos trabajan juntos para compartir sus experiencias e integrarlas en una biblioteca de clases y una base de conocimientos comunes. En contraste, los equipos de desarrollo basados en JVM a menudo tienen que aprender lecciones importantes repetidamente. /p>
Por ejemplo, una de las características de JRuby es su compilador JIT Just In Time. Este compilador convertirá el código Ruby en código de bytes Java en tiempo de ejecución. El problema es que en la versión actual, dicho código lo basará. en los depuradores set_trace_func (estos depuradores usan devoluciones de llamada para implementar funciones de depuración) no funcionan correctamente porque el código ya no llama a esta devolución de llamada. Esto significa que la depuración de JRuby se ve afectada de esta manera y definitivamente ocurrirá el mismo problema en cada lenguaje procesado y. resuelto, así que *** compartir incluso una pequeña parte de esta experiencia o código ayudará a otros a ahorrar tiempo y trabajar lishixinzhi/Article/program/Java/JSP/201311/19372