El API para JSON no formará parte de Java 9
Abraham
Una de las características que se suponía que iba a traer Java SE 9 (prevista para mediados de 2016) era un API para trabajar con JSON. Esto era un movimiento bastante lógico; si tenemos un parser de XML dentro de Java, en estos momentos parece lógico tener también un parser de JSON.
Sin embargo, sin dar demasiadas explicaciones sobre el porqué, Mark Reinhold, principal arquitecto de Java SE, ha dicho que este API no va a formar parte de Java 9, que quizá se considere para Java 10. También ha dicho que una vez este API no va a formar parte de Java 9 Oracle está re evaluando que otra funcionalidad se puede incluir dentro de Java 9 una vez los recursos que estaban destinados a este API no se van a emplear.
¿Qué os parece este movimiento por parte de Oracle? ¿Veiais vosotros interesante el incluir el API de JSON en Java SE 9?
Reader Comments (10)
No me parece la muerte de nadie.
Yo vengo utilizando google-gson desde hace un par de años con muy buen resultado.
Un saludo,
Al final Java 9 va a ser Jigsaw y nada más... o todo lo demás menos Jigsaw (otra vez)
Teniendo en cuenta que JSON es un estándar en el intercambio de información en Internet, en mi opinión, el hecho de no incluir un API, que estaba previsto, nada más y nada menos que para 2016 (creo que tenían tiempo) es una cagada (otra más) en él devenir de Java
Desde que Oracle tomó el desarrollo de Java no veo que hagan grandes avances... es una pena que no tengan en cuenta JSON que es la forma más lógica de conectarse con una aplicación desarrollada en JavaScript en vez de XML.
Es cierto que uno puede agregar librerías de terceros todo el tiempo, pero con ese criterio seguiría programando con Java 5.
Java solía gustarme, pero hacen todo lo posible para que sienta que está cayendo en un punto muerto.
Es increible que la API de Java no tenga un parser para JSON a esta altura, es algo esencial para el trabajo diario. Una humilde opinion nada mas.
La parte que a mí más me fastidia de esto es que realmente no han dado ningún motivo. Nada en plan "creemos que no es un estándar maduro" o yo que sé que, aunque no te convenza la explicación.
Yo creo que no hay que dramatizar como dice @JuanCarlos se puede añadir librerías de terceros y seguimos funcionando sin problemas.
Otro debate es el que Oracle no esté apostando fuerte por Java y las innovaciones no van llegando. Por lo menos no ha hecho como con MySQL, Glassfish,... que los están dejando morir y esto se lo toma mucho más en serio, en parte creo que porque también forma parte del Core de su Stack tecnológico.
La verdad es que fue una pena que SUN fuera comprada y desmantelada pero esto es adaptarse o morir.
Saludos.
En realidad sí existe un JSR para JSON, e incluso existe la implementación de referencia:
* JSR: JSR 353 - Java API for JSON Processing.
* Implementación de referencia: jsonp.
* Un enlace interesante sobre json de Oracle.
Esa implementación de referencia es la que iba a formar parte de JEE. Si queréis adelantaros, ya sabéis, podéis echarle un vistazo.
Leyendo el artículo, creo que la razón es :
“We may reconsider this [JSON API] JEP for JDK 10 or a later release, especially if new language features such as value types and generics over primitive types (JEP 218) enable a more compact and expressive API.” – Mark Reinhold
Es decir, piensan que es mejor añadir primero otras cosas, para que luego quede mejor el API, lo cual me parece sensato, sabiendo que hay APIs de 3º o como dice Ramón un JSR que ya te permite tratar JSON. En mi experiencia en realidad se usa más para intercambio de datos y las librerías de alto nivel, como JERSEY, lo suelen ocultar.
Personalmente el JSON estándar (al igual que el javascript) no me gusta, por lo menos lo que he tratado con él, no puedes poner comentarios, solo admite floats, no hay encoding, etc...
Un saludo,
DreamTangerine.
Hola,
Personalmente creo que es una decisión acertada, porque entre otras cosas el JSON (las soluciones basadas en) está muy verde respecto a nuestro querido y antiguo, fiable y "seguro" SOAP (cifrado, firma, transaccionalidad, sellado tiempo etc. y todo en las cabeceras WSIT).
Veamos la especificación OAUTH, menos "segura" en su versión 2 que la 1, o las dificultades de generar automáticamente los clientes a partir del WSDL, perdón WADL del JSON. A trancas y barrancas, se intenta conseguir una funcionalidad mínima similar al WSIT, porque es simplemente necesario para cuando quieres hacer cosas un poquito mas serias.
Sin querer polemizar, creo que el futuro prometedor del JSON pasa por las mejoras en los navegadores para suplir de facto estas funciones, como la discusión en el W3C sobre la posibilidad de "standarizar" que desde el JAVASCRIPT, se pueda solicitar al navegador la firma de un TOKEN con alguno de los certificados instalados por el usuario.
Claro, que con lo despistados que van pues mejor usar mientras librerías de terceros que además funcionan estupendamente, y ya veremos si el tema se formaliza.
Un saludo.