Los vídeos sobre Jakarta EE (Java EE) se van a ir subiendo a esta lista: ua-cam.com/play/PLTd5ehIj0goMhqWg_v2CbIZf_Ed2jqE-r.html Para todas tus necesidades de Java, recuerda revisar el resto de mis listas: www.makigas.es/temas/java Estamos en el canal #java de Discord para lo que pueda hacerte falta: discord.gg/makigas-329487017916366850
Cuando ingressas al universo Java, eres golpeado por una lluvia d siglas, lo q puede ser muy intimidante! Entonces, un tutorial sencillo y direto t ayuda mucho! 👏🏽👏🏽
Hola, muchas gracias por esta información. Estoy aprendiendo Java EE y me rompía la cabeza eso de Jakarta y la incompatibilidad del paquete javax con Tomcat 10. Saludos desde Chile
Más o menos, lo voy a reiniciar porque realmente se ha quedado atrás con esto del cambio de nombre. (Por ejemplo, de javax.persistence.Entity hemos pasado a jakarta.persistence.Entity y cuantos más años pasen desde que se hizo el cambio de nombre más confuso va a ser). Pero esta vez la intención sí es terminarlo xD
Hola! Gracias por el vídeo. Creo que me confunde un poco el cambio de nombre de Java y Jakarta... Quiero instalar un Tomcat 10, ¿Necesito instalar también Jakarta? Creo que en las especificaciones dice que es compatible con java 11, pero no consigo entender entonces por qué tomcat necesita una herramienta de migración a Jakarta si aún se puede ejecutar con Java...
¿Dos tecnologías que implementen la misma especificación Jakarta EE, por ejemplo, JPA, usan la misma nomenclatura para las clases, propiedades, métodos, interfaces, etc, es decir, le dan los mismos nombres?
Sí. Tienen que hacerlo para hacerlas intercambiables. Existe una cosa llamada el TCK que es como una serie de tests y validaciones que le pasan a las bibliotecas de este estilo para poder confirmar que son compatibles. Por ejemplo, - Los resultados del TCK de EclipseLink: www.eclipse.org/eclipselink/releases/tck-summary.php - Los resultados del TCK de Hibernate ORM: github.com/hibernate/hibernate-orm/blob/main/tck/summary.md Hay algunas partes que no son compatibles. Por ejemplo, me quiere sonar que al final en EclipseLink la configuración de conexión a la BBDD es propia, igual que en Hibernate. Y luego cada biblioteca es libre de implementar sus propias lógicas propias (por ejemplo, Hibernate tiene su propio query language aparte del que le obliga a implementar JPA); pero desde luego las anotaciones tipo @Entity, @Id, @GeneratedValue... son estandar.
@@makigas Muchas gracias Dani por tan valiosa explicación, que corrobora la compatibilidad entre las tecnologías que implementen una misma especificación Jakarta, pero que también indica que cada tecnología puede añadir sus propias funcionalidades.
Pues la principal alternativa a Jersey sería Apache CXF, esa también es compatible con la creación de servicios REST en Java. cxf.apache.org/ De algún modo Jersey es la implementación de referencia y por ello suele ser la que más se usa. También es importante notar que aunque hay cosas de Spring que son parcialmente compatibles con otros estándares de Jakarta, la implementación de REST en Spring no es compatible con JAX-RS en este momento.
Se sigue llevando, se está empezando a ver demanda de frameworks Microprofile como Quarkus porque se llevan mejor con microservicios que Spring, y todo eso está levantado encima de Jakarta.
Hola Dani. Muchas gracias por el video. Quiero aprender Spring pero tengo algunas dudas. Por ejemplo entiendo que Spring implementa también JPA pero Spring no es Jakarta. ¿Que le falta a Spring para ser Jakarta? o ¿estoy mezclando locamente las cosas?
Es que es un panorama un poco complicado. Partamos de la base de que una aplicación Spring básica no usa tecnologías de J-EE. Hay algunos addons que si se meten a la app, sí vienen de ahí. El ejemplo más típico es el que dices: Spring Data JPA permite usar entidades de JPA por ejemplo con Hibernate. Otro ejemplo es la inyección de dependencia. Autowired es la de Spring, pero hoy día se puede usar Inject como alternativa, y esa es también viene de J-EE. Se comportan igual, es más una cuestión de qué clase importar. Bean Validations es otra biblioteca que suele pasar desapercibida pero hay veces que se puede instalar en Spring y que viene igualmente de J-EE.
Los vídeos sobre Jakarta EE (Java EE) se van a ir subiendo a esta lista: ua-cam.com/play/PLTd5ehIj0goMhqWg_v2CbIZf_Ed2jqE-r.html
Para todas tus necesidades de Java, recuerda revisar el resto de mis listas: www.makigas.es/temas/java
Estamos en el canal #java de Discord para lo que pueda hacerte falta: discord.gg/makigas-329487017916366850
Cuando ingressas al universo Java, eres golpeado por una lluvia d siglas, lo q puede ser muy intimidante! Entonces, un tutorial sencillo y direto t ayuda mucho! 👏🏽👏🏽
La mejor explicacion sobre Jakarta EE que he encontrado, y encima viene con playlist, na re god tu canal man. Un abrazo
Hola, muchas gracias por esta información. Estoy aprendiendo Java EE y me rompía la cabeza eso de Jakarta y la incompatibilidad del paquete javax con Tomcat 10. Saludos desde Chile
Vamosss ya... una lista de videos sobre java...
Ya tengo algo que ver en mi tiempo libre
Gracias majo, +1
Super clara la explicación. Muchas gracias por el vídeo
Esto me aclara muchas dudas, espero mas videos similares.
Excelente explicación
gracias amigo, puedes seguir explicando mas cosas sobres java explicas muy bien
pd:estouy iniciando en este hermoso mundo
Buen video!, para cuando el curso de jakarta EE?
Excelente video! Tienes pensado continuar el curso de JPA + Hibernate? Está buenísimo
Más o menos, lo voy a reiniciar porque realmente se ha quedado atrás con esto del cambio de nombre. (Por ejemplo, de javax.persistence.Entity hemos pasado a jakarta.persistence.Entity y cuantos más años pasen desde que se hizo el cambio de nombre más confuso va a ser). Pero esta vez la intención sí es terminarlo xD
Hola! Gracias por el vídeo. Creo que me confunde un poco el cambio de nombre de Java y Jakarta... Quiero instalar un Tomcat 10, ¿Necesito instalar también Jakarta? Creo que en las especificaciones dice que es compatible con java 11, pero no consigo entender entonces por qué tomcat necesita una herramienta de migración a Jakarta si aún se puede ejecutar con Java...
Muy bien explicado maquina😁
¿Dos tecnologías que implementen la misma especificación Jakarta EE, por ejemplo, JPA, usan la misma nomenclatura para las clases, propiedades, métodos, interfaces, etc, es decir, le dan los mismos nombres?
Sí. Tienen que hacerlo para hacerlas intercambiables. Existe una cosa llamada el TCK que es como una serie de tests y validaciones que le pasan a las bibliotecas de este estilo para poder confirmar que son compatibles. Por ejemplo,
- Los resultados del TCK de EclipseLink: www.eclipse.org/eclipselink/releases/tck-summary.php
- Los resultados del TCK de Hibernate ORM: github.com/hibernate/hibernate-orm/blob/main/tck/summary.md
Hay algunas partes que no son compatibles. Por ejemplo, me quiere sonar que al final en EclipseLink la configuración de conexión a la BBDD es propia, igual que en Hibernate. Y luego cada biblioteca es libre de implementar sus propias lógicas propias (por ejemplo, Hibernate tiene su propio query language aparte del que le obliga a implementar JPA); pero desde luego las anotaciones tipo @Entity, @Id, @GeneratedValue... son estandar.
@@makigas
Muchas gracias Dani por tan valiosa explicación, que corrobora la compatibilidad entre las tecnologías que implementen una misma especificación Jakarta, pero que también indica que cada tecnología puede añadir sus propias funcionalidades.
Excelente video bro ! , puedes dar más especificaciones con "Jax-rs"
Pues la principal alternativa a Jersey sería Apache CXF, esa también es compatible con la creación de servicios REST en Java. cxf.apache.org/
De algún modo Jersey es la implementación de referencia y por ello suele ser la que más se usa. También es importante notar que aunque hay cosas de Spring que son parcialmente compatibles con otros estándares de Jakarta, la implementación de REST en Spring no es compatible con JAX-RS en este momento.
Buenas! ¿Vale la pena estudiar esto en 2024 o se lleva mas Spring? Gracias!
Se sigue llevando, se está empezando a ver demanda de frameworks Microprofile como Quarkus porque se llevan mejor con microservicios que Spring, y todo eso está levantado encima de Jakarta.
muy buena explicacion
Hola Dani. Muchas gracias por el video. Quiero aprender Spring pero tengo algunas dudas. Por ejemplo entiendo que Spring implementa también JPA pero Spring no es Jakarta. ¿Que le falta a Spring para ser Jakarta? o ¿estoy mezclando locamente las cosas?
Es que es un panorama un poco complicado. Partamos de la base de que una aplicación Spring básica no usa tecnologías de J-EE. Hay algunos addons que si se meten a la app, sí vienen de ahí. El ejemplo más típico es el que dices: Spring Data JPA permite usar entidades de JPA por ejemplo con Hibernate. Otro ejemplo es la inyección de dependencia. Autowired es la de Spring, pero hoy día se puede usar Inject como alternativa, y esa es también viene de J-EE. Se comportan igual, es más una cuestión de qué clase importar. Bean Validations es otra biblioteca que suele pasar desapercibida pero hay veces que se puede instalar en Spring y que viene igualmente de J-EE.
Gran video
Pole?
Creo que JPA usaría JDBC por debajo. Quizás por eso la menciona.
Otra cosa, creo que JSF es exclusivo de Jakarta y JSP era de Java EE.
No no, JSP también ha pasado a ser un proyecto de Jakarta. Le cambiaron el nombre por Jakarta Server Pages para no cambiar las siglas y a correr xD
Gracias crack.
un lujo