Hoy en nuestro estudio virtual, el orador más famoso del mundo para Spring es Josh Long.

Sus informes abren conferencias de Java en todo el mundo. Es él quien responde las preguntas de la comunidad, hace Spring Tips en YouTube, es su "Esta semana en primavera" que leemos todas las semanas y mucho más.

Por cierto, Josh permitió usar todos los materiales en nuestro propio "Esta semana en Java" , pero lo hace en tal volumen y profundidad que estos datos nunca se han podido comprimir al formato de "resumen de 15 minutos".

A veces parece que está en todas las ciudades al mismo tiempo, lee informes y escribe artículos en un momento. Hoy descubriremos cómo lo hace. Aprendemos sobre la "jurisdicción del código", las razones de la increíble vitalidad de Spring y cómo logró vivir tantos años sin una reescritura global desde cero y otros trucos interesantes.

Miembros

Josh Long, defensor del desarrollador de primavera en Pivotal

Evgeny Trifonov, Oleg Chirukhin - editores del grupo JUG.ru

Todo el mundo sabe que viajas mucho, pero sería interesante si pudieras dar algunas estadísticas: cuántas conferencias asististe el año pasado, cuántos vuelos hiciste y cosas similares.

Buena pregunta Tengo una tabla que registra todas las reuniones a las que asisto durante el año. Mi asistente, Tasha, me ayuda a organizar el horario y esta tabla. Entonces, abramos esta tableta en el teléfono ... Doscientos cuarenta. En 2018, en este momento, asistí a 240 eventos diferentes. Algunas de estas reuniones tienen lugar en línea (como la nuestra), pero tengo que volar a la mayoría. Durante este año, volé más de medio millón de millas. Permítanme verificar la distancia de la Tierra a la Luna ... Son 239 mil millas, para poder volar a la Luna y regresar.

"A la luna y de regreso de la primavera". Buen título para el libro de Tolkien.

¿Las aerolíneas le ofrecen ofertas especiales porque vuela mucho?

Bueno, no me quejo del servicio. A menudo vuelo con United Airlines y tienen un programa de Servicios Globales. Puede llegar allí solo si recibe una invitación; usted mismo no puede solicitarla por sí mismo y se desconoce qué criterio tiene. Todos los años invitan a las personas que vuelan con mayor frecuencia. El año pasado, alguien dijo que seleccionaron el 1% de los clientes más frecuentes en todo el mundo. O tal vez se filtran por la cantidad de costos. De una forma u otra, me tratan muy bien. Esto es lindo Pero incluso en este caso, creo, para la mayoría de las personas, los vuelos son una carga. Definitivamente me preocupa. No vuelo para los vuelos en sí, sino para conocer gente que usa Spring. Me teletransportaría si hubiera tal oportunidad. La vida sería mucho más simple y más interesante.

Buena razón para esperar a Hyperloop.

Sí, pero esto tendrá que esperar mucho tiempo.

Hablemos de un tema más cercano a la primavera. Hablas de esto con personas de todo el mundo. ¿Hay alguna diferencia regional en su prevalencia?

Yo no diría Spring siempre ha sido 100% de código abierto, y mientras la gente escriba software que funcione en Internet, Spring seguirá teniendo éxito en todo el mundo. Es cierto que hay otros proyectos de código abierto en los que la especificidad regional es notable. No puedo confirmar las estadísticas ahora, pero me parece que GridGain es muy común en Rusia.

Si es verdad.

Y en China, MyBatis es muy popular. En los Estados Unidos y Europa, no lo he visto en 10 años, y en China es tan común como la primavera. Y, de hecho, MyBatis no tiene nada de malo, es rápido y potente, así que ¿por qué no usarlo?

Hicimos un proyecto en el que MyBatis trabaja con GridGain, está ahí dentro.

(Risas) Así que los usas a ambos, ¡genial! Me gustan ambas tecnologías. No había un soporte normal para MyBatis, y constantemente preguntaba a varias grandes compañías en China que estaban haciendo cosas increíbles: ¿por qué necesitaban MyBatis con Spring? Hay muchas otras opciones, Hibernate funciona muy bien y MyBatis prácticamente no se usa en Occidente. Como resultado, decidí que una vez que se utiliza el programa, es necesario garantizar su funcionamiento normal. Si echa un vistazo a las fuentes Spring Boot Starter para MyBatis ahora, verá mi nombre allí. Quería que aquellos que necesitan este programa en el este puedan trabajar normalmente con él. En general, una parte importante de mi trabajo proviene del tipo de descubrimientos que hago en diferentes países durante mis viajes.

Usted es el defensor fundamental de los desarrolladores para los proyectos de primavera. ¿Qué significa esto en la práctica? ¿Qué estás haciendo exactamente?

Una pregunta difícil El concepto de Developer Advocate se ha extendido gracias a Apple y, en particular, a Microsoft. Comenzó hace unos 30 años, cuando Microsoft se dio cuenta de que eran los desarrolladores los que tenían la fuerza real. Si desea que su plataforma sea exitosa y útil, necesita desarrolladores para crear cosas nuevas y valiosas en esta plataforma. En consecuencia, debe convencerlos de los beneficios de su plataforma. Microsoft comenzó a tratar de motivar a los desarrolladores de diferentes maneras. Hicieron que Visual Studio fuera muy barato, es decir, proporcionaron herramientas asequibles. Crearon muchas API muy interesantes con las que puedes trabajar en Windows. En general, Microsoft se dio cuenta de que era necesario colaborar con la comunidad. La gente no confía en el software, sino en otras personas. Las personas no tienen ningún apego emocional al software. Puede imaginar todo lo que quiera que se hará famoso simplemente escribiendo un programa en soledad en su habitación de hotel, y cualquiera que lo necesite encontrará la documentación por sí mismo. Pero en realidad esto generalmente no sucede. Una parte importante de mis responsabilidades es comunicarme con personas de la comunidad. Escucho lo que dice la gente y lo llevo a los desarrolladores, y luego paso a la comunidad lo que dicen los desarrolladores. En otras palabras, soy una especie de vehículo.

El equipo de Spring es raro y hermoso. Ella ya tiene más de una década y media. Al principio, ella era muy pequeña, y los desarrolladores mismos se dedicaban a la consultoría. Trabajaron constantemente con otros equipos, ayudándoles a crear su propio software, es decir, resolvieron problemas reales y no se quedaron encerrados en una torre de marfil. No pretendieron saber de antemano qué software se necesitaba, sino que escribieron lo que otros realmente necesitaban, y su beneficio siempre fue su criterio principal. Compartieron con sus clientes su sufrimiento para resolver problemas. No creamos cosas inútiles. Y esto, como saben, a menudo es un problema al crear software. De hecho, el primer equipo de Spring ya estaba formado por Promotores defensores. No eran similares a lo que los programadores suelen representar. Sí, eran desarrolladores talentosos, pero al mismo tiempo discutieron con entusiasmo sus ideas con otras personas, asistieron a presentaciones, conocieron personas, se hicieron conocidos y mantuvieron diálogos. Gracias a esto, Spring rápidamente ganó gran popularidad.

El problema es que este enfoque no escala bien. Es imposible para todos los desarrolladores pasar la mitad de su tiempo viajando, chateando y reuniéndose. Cuando me uní al equipo, ya estaba escribiendo código para Spring, ya que es un proyecto de código abierto. Además, ya había publicado libros, escribí artículos e hice presentaciones. Así que ya traté de presentar Spring a la comunidad lo mejor posible y darle a la mayor cantidad de personas posible la oportunidad de conocerlo. Por lo tanto, el equipo de Spring me invitó a hacer lo mismo, pero de manera continua y por dinero. Creo que soy 80% Developer Advocate y 20% programmer, mientras que el resto del equipo Developer Advocate es 20% y 80% programmers.

En general, mi trabajo es mantenerme en contacto con la comunidad, y hay muchas maneras diferentes de hacerlo. Estoy escribiendo mi sexto libro, se llama The Reactive Spring Book; el anterior fue publicado por O'Reilly llamado Cloud Native Java. Hice muchos tutoriales en video que puedes ver en Safari Books Online , cada uno de los cuales demora de 4 a 5 horas. Además, todos los miércoles publico videos de Spring Tips en YouTube , cada uno de los cuales está dedicado a un aspecto específico del ecosistema. Suelen durar de 45 minutos a una hora, cada año hago al menos dos temporadas, a veces tres. Así, de año en año, cada dos semanas preparo suficiente material para un informe completo en la conferencia. A partir de enero de 2011, todos los martes, sin excepción, hago una nueva entrada de blog, "Esta semana en primavera" , en la que reviso todo lo más interesante del ecosistema. También tengo otros blogs, las últimas dos noches he estado haciendo exactamente eso. Además de esto, también escribo código y hablo en conferencias. Por lo tanto, mi trabajo incluye el máximo de una amplia variedad de actividades, pero podría limitarme a una sola cosa. Hay personas que simplemente bloguean o simplemente hacen videos, y lo hacen muy bien. Algunos ni siquiera viajan, sino que realizan seminarios en línea. Mi enfoque es diferente de los demás, pero, en última instancia, toda esta actividad persigue el mismo objetivo.

Por cierto, mis responsabilidades también incluyen hacer tutoriales, bloguear, etc. Para mí es muy difícil y puede llevar una cantidad arbitraria de tiempo. ¿Qué tan difícil se te da? Digamos cuánto tiempo lleva preparar un video de Spring Tips.

Olvidé decir: tengo un nuevo podcast, todavía no ha salido nada, pero ya se han preparado siete entrevistas :-) En cuanto al tiempo de preparación, sucede de manera diferente. Si ya estoy familiarizado con el tema que decidí cubrir, entonces solo tengo que sentarme y grabar todo dos o tres veces, siempre cometo muchos errores. Tarda unas cuatro horas una vez a la semana, es decir, un poco. Pero en otros casos esto no es suficiente. A veces estudio un problema y tomo notas sobre él durante muchos meses, y luego decido que, dado que este trabajo ya se ha realizado, ¿por qué no hacer un video de estas notas? Estoy constantemente aprendiendo, como probablemente tú lo estés. Pero las situaciones en las que necesito aprender algo específicamente para el video son raras. La parte más difícil aquí es decidir qué necesita para sentarse y profundizar en el tema, y ​​no el proceso de estudio en sí.

A veces, los programadores de nuestro equipo lanzan algo que nadie ha creado antes. En esta situación, las personas, por supuesto, tendrán preguntas, y estas preguntas caerán por defecto en los programadores. Y puedo hacer un video donde se explicará todo y subirlo previamente a la red para que las personas tengan tiempo de conocerse. Obviamente, en esta situación, también tengo que aprender, ya que estamos hablando de algo completamente nuevo.

¿Cuántos proyectos existen actualmente en primavera?

Buena pregunta Creo que unas pocas docenas. Existen módulos muy especializados, algunos de los cuales son desarrollados por la comunidad, algunos por el equipo de Spring en Pivotal u otras grandes empresas. Todo el soporte para Google GCP se realizó en Google, soporte para Microsoft Azure - en Microsoft. Pero mucho, como MyBatis, por ejemplo, está siendo desarrollado por la comunidad. Además, tenemos módulos separados, por ejemplo, Spring Data Neo4j, un módulo para la base de datos de gráficos Neo4j. Es parte del proyecto Spring Data, pero se realizó en colaboración con Neo4j, hicieron el trabajo principal en este proyecto, él solo vivía en nuestro repositorio git. Hay muchos ejemplos de este tipo.

En cuanto a Spring Boot, tenemos un maravilloso mecanismo que funciona con él llamado Configuración automática. Proporciona a las personas una forma conveniente de agrupar en qué trabajarán. La persona simplemente descarga el archivo JAR en su classpath, y se agrega automáticamente a la aplicación Spring Boot en ejecución. Hay muchas configuraciones automáticas de este tipo en el ecosistema, pero no conozco una parte importante. Funcionan como complementos.

¿Y cómo entender a los usuarios en toda esta variedad de proyectos? ¿Hay alguna estructura general o idea?

Lo más probable es que no necesite todos los proyectos. Designe su objetivo y seleccione el proyecto deseado basado en él. No me gusta cuando la gente trata de "aprender la primavera", este es un ejercicio sin sentido. La pregunta debe plantearse así: necesito escribir, digamos, una API REST. Mi primer paso es ir a spring.io/guides , donde puede encontrar una guía simple y económica que demore entre 10 y 15 minutos. Tendrá todo lo que necesita saber: qué código escribir, en qué carpeta, cómo hacerlo en IntelliJ o en Eclipse o en otra cosa. Tratamos de explicar todo con gran detalle y no omitimos nada, porque queremos que estas guías sean accesibles para todos. Hagas lo que hagas: JMS, Neo4j, seguridad, disyuntores, Kafka, tenemos una guía separada para cada tema. Decida su tarea y seleccione la guía adecuada. Debe pensar no en Spring, sino en lo que integrará su sistema: Spring es solo una herramienta que permite esta integración. Por lo tanto, no tiene sentido "aprender Spring": debe usarlo si puede simplificar su tarea específica.

¿Qué proyectos en primavera son, en su opinión, los más prometedores? ¿O el más subestimado?

La biblioteca Spring Retry es muy popular. Fue desarrollado originalmente en Spring Batch. No sé si alguna vez ha usado Spring Batch, le permite procesar grandes volúmenes de datos transmitidos secuencialmente, por ejemplo, documentos del sistema de archivos, archivos XML, CSP, etc. En un caso de uso para esta herramienta, lee un registro y luego lo escribe, por ejemplo, desde un servicio web a una cola de mensajes. El procesamiento de estos datos puede llevar horas, y sería extremadamente indeseable si el sistema, debido a un error al final, retrasara todo el trabajo realizado durante la noche. No puedes hacer eso. Spring Batch funciona con paquetes de datos; procesa registros no uno, sino diez o mil. Incluso si se pierde el procesamiento de miles de registros, todo el resto se guardará. Además, al escribir sistemas de paquetes, debe tener en cuenta que necesita acceder a otros servicios que pueden fallar. Hay Spring Retry para esto. Esta biblioteca le permite realizar repetidas llamadas a los servicios. Además, puede usar la velocidad de obturación exponencial. Además de Spring Batch, Spring Retry también se usa en Spring Integration, Spring Cloud Stream, Spring Cloud Data Flow. En los últimos dos, apoyamos Spring Retry debido a su conexión con otras cosas. Por lo tanto, esta biblioteca se usa en muchos proyectos de Spring, y no estoy seguro de que todos lo sepan. Spring Retry es una biblioteca de uso muy frecuente que a veces simplemente se pasa por alto. En general, tenemos muchas cosas reactivas diferentes. Suelen ser los más interesantes.

¿Por qué exactamente el reactivismo?

Tenemos reactividad en todas partes. La ventaja de Spring es que puede comenzar y finalizar un proyecto con él. Esta semana anunciamos que apoyaremos el proyecto Facebook RSocket . Este es un análogo completamente reactivo de gRPC, pero significativamente más flexible. Se puede usar para pub / sub, transmisión de datos, solicitud / respuesta del cliente; en general, con él puede implementar muchos patrones de mensajería diferentes. Y se usa en Facebook. Hay dos paquetes, uno en C ++, el otro en Java. El de Java se escribe usando Reactor, nuestra biblioteca reactiva. Ella usa Salesforce. Por supuesto, hay otras opciones. ¿Has oído hablar de gRPC de Google? Es de muy alta calidad e interesante, pero no es reactivo, por defecto no funciona bien con los tipos reactivos. Salesforce gRPC no tiene este inconveniente. Tiene un compilador que crea servicios basados ​​en Spring Reactor. Entonces, tanto Facebook como Salesforce pudieron escalar Reactor a sus necesidades.

El propio reactor es uno de nuestros proyectos más interesantes. RxJava salió antes, pero Reactor fue el primero en proporcionar soporte de hilos reactivos. Esto sucedió en gran medida porque el maravilloso programador David Karnock, gerente de proyectos de RxJava, trabajó con nosotros en Reactor. Entonces, una parte significativa de todas las cosas nuevas e interesantes que sucedieron en nuestro ecosistema de alguna manera tocaron a Reactor. Gracias a esto, el proyecto se ha vuelto extremadamente atractivo para las empresas que crean grandes sistemas. Reactor también subyace en el marco Spring WebFlux. Además, basados ​​en Reactor, brindamos soporte para mensajería reactiva, tomas de red reactivas, Spring Cloud Stream, disyuntores reactivos, etc. Todos estos componentes pueden integrarse en aplicaciones reactivas. Por supuesto, puede usar Spring, pero prefiero usar todo el ecosistema con estos tipos reactivos.

Además de esto, recientemente hicimos un anuncio sobre R2DBC, nuestra API para acceder a datos basados ​​en SQL para controladores reactivos. JDBC reactivo aún no existe. El problema es que si usa código reactivo, entonces no puede usar el bloqueo. Si se usa el bloqueo, entonces esta interacción debe ampliarse, aumentando el número de subprocesos. Y esto contradice el objetivo original, ya que solo queremos evitar escalar aumentando el número de hilos; esto es demasiado costoso. Por lo tanto, R2DBC proporciona una abstracción que proporciona acceso a datos reactivos. Hay controladores de bases de datos que inicialmente son reactivos, por ejemplo, Postgres. Por lo tanto, puede usar R2DBC, entre otras cosas, con Postgres y trabajar con SQL reactivo sin usar un bloqueo, ya que no tiene subprocesos. Todo este tema me parece extremadamente interesante.

¿Quizás podría responder algunas preguntas técnicas frecuentes? Uno de los problemas es que cuando se usan múltiples proyectos Spring, muchas anotaciones ocurren simultáneamente. Se hace difícil descubrir qué hace cada uno de ellos: no puede hacer clic en él mientras mantiene presionada la tecla Ctrl e ir a la definición. ¿Cómo comportarse en tal situación?

Debe ejecutarse con la opción `--debug`. La mayor parte del ecosistema de Spring ahora existe como una configuración automática. Alguna parte es como una configuración importada, si en este caso hace clic en la anotación, verá la inscripción `@ Importar`, que luego indicará su clase. Si luego hace clic en él, verá los objetos que se crearon para usted. Pero a veces Spring actúa a través del mecanismo de configuración automática; en esta situación no se crean anotaciones. Solo hay una biblioteca y classpath. Entonces es realmente difícil descubrir qué está sucediendo y por qué. Pero queremos que sea lo más fácil posible para las personas resolver esto. Para esto, existe el parámetro `--debug`, que debe ingresarse cuando se inicia la aplicación. Luego verá un informe en el que se describirán todos los pasos realizados por la aplicación al inicio. La aplicación verifica si existen algunos campos o clases y, dependiendo de esto, decide si creará algunos objetos para ellos o no. El informe muestra qué condiciones se cumplieron, cuáles no y qué configuraciones no dependieron de ninguna verificación. Entonces, si, por ejemplo, no puede entender por qué su conexión con Kafka no funciona, puede ver la condición correspondiente, tal vez no tenga la clase requerida en el classpath.

Ahora habrá una pequeña pregunta de trolling. Los opositores de Spring a menudo afirman que es la causa de una arquitectura de baja calidad, porque simplemente puede usar @Autowired cualquier lugar y en todas partes. ¿Estás de acuerdo con esta opinión? Hace diez años, la arquitectura se creó en tres capas, los valores se transfirieron del constructor al constructor y se crearon DTO. Con Spring, puedes deshacerte de todo esto. ¿Es bueno o malo?

La primavera es una herramienta. Permite a más personas crear software que llega a producción y funciona correctamente, por lo que no creo que sea dañino. En los últimos años, millones de personas han creado aplicaciones que lo utilizan, y todo funciona bien para ellos. Considerar que Spring en su conjunto es dañino es absurdo, esa opinión no puede llamarse ignorante.

En primavera, puede crear un cableado bastante explícito. Si le preocupa que no quede claro de dónde proviene el objeto dado, puede atarlo usted mismo. Puede crear una configuración de Java en la que un método llamará a otro, y el valor de salida del método llamado será un bin - Spring se encargará de ello. Incluso cuando llame al mismo bin varias veces o miles de veces, nunca tendrá más de un enlace si este objeto es un singleton. Desea que todo sea explícito, se puede hacer. Si lo desea, puede recurrir a una opción aún más aburrida: XML. La conclusión es que si no desea utilizar `@ Autowired`, esto puede evitarse por completo.

Si usa Spring Boot de la manera más común, solo tendrá un bean. Sabe que necesita un bean del tipo `ConnectionFactory`; en este caso, no hay ningún problema para realizar una inyección por tipo. Todavía solo tiene un objeto, no tendrá dos `ConnectionFactory` para una` Connection`. No tendrá dos sesiones de Hibernate, por lo que nada le impide inyectar 'HibernateSession'; todavía existe en una sola instancia. Si desea que todo sea explícito, puede usar la anotación `@ Qualifier`. Con él, marca lo que inyecta por tipo. Esto permitirá distinguir las diversas implementaciones de bin entre sí. Supongamos que tiene un servicio con el cual las aplicaciones en un lugar pueden comunicarse con iTunes, en otro, con Amazon, en el tercero, con Android Play Store. Serán tres beans diferentes de un tipo diferente, pero cada uno tendrá la anotación `@ Qualifier`. Además, esta anotación se puede superponer a otra anotación, lo que garantiza la seguridad de los tipos. Enlazará este tipo y tendrá una anotación encima, y ​​cuando se cree el bean, tendrá la anotación `@ Qualifier`, incluso en el sitio del consumidor. Por lo tanto, estas anotaciones le proporcionarán enlaces, e incluso si tiene tres implementaciones mientras el programa se está ejecutando, aún puede encontrar la que necesita.

Es decir, en general, en su opinión, la flexibilidad es una característica positiva. ¿Usted y el equipo de Spring se adhieren a algunos principios fundamentales como el Zen Zen?

Sí, adherirse a. Por cierto, he estado programando en Python desde finales de los 90, y soy un gran defensor de Python Zen, tiene una idea general muy correcta. En cuanto a su pregunta, aquí debe hablar sobre Jürgen Höller, cofundador de Spring y el segundo desarrollador que trabajó en el proyecto. Este es un hombre encantador, muy tranquilo, uno de los mejores con los que tuve que comunicarme. Es muy fácil hablar con él si, por ejemplo, lo conoció en una conferencia. Al mismo tiempo, tiene un intelecto poderoso y su contribución a Spring es difícil de sobreestimar. La conferencia JAX, muy importante, aunque, por supuesto, no llega al Joker :), le otorgó un premio especial por el trabajo que nadie más había recibido antes. Por lo general, los premios se otorgan en alguna categoría especial, pero esta no tiene categoría y pertenece solo a Jürgen. Spring es el único proyecto en el ecosistema de Java que nunca se ha reescrito en 15 años, porque no es necesario. Jürgen tiene una idea muy clara de cómo escribir módulos, cómo expresar tipos, en general: cómo crear una base de código de alta calidad que pueda vivir durante décadas y cambiar fácilmente si es necesario. No hay otros proyectos similares en el ecosistema de Java. Una parte importante de los proyectos ya no existe, e incluso entre los que se han reescrito desde cero, muy pocos han vivido 15 años.

Sin ser reescrito, solo Spring duró 15 años, porque fue escrito de manera muy limpia desde el principio. Jürgen nos enseñó algunos principios fundamentales que seguimos: cómo hacer módulos, cómo hacer paquetes de implementación (en oposición a la parte pública), cómo describir el nivel de superficie de la API y los tipos de diseño para ella, qué patrones deben usarse. Con Spring, inevitablemente te familiarizas con los patrones de diseño, y siempre ha sido así. Me viene a la mente un ejemplo del patrón Patrón. Spring Integration le presenta los patrones de integración empresarial, Spring MVC presenta MVC. Todos estos patrones son parte del marco y los usamos en base a prácticas comprobadas. Nuestro zen son los principios que Jurgen nos enseñó. En este sentido, todos somos sus alumnos. Jürgen es conocido por su enfoque un poco extraño sobre cómo escribir código, debido a su estilo, incluso surgió un término especial, "jurgenizar". Nuestro equipo tiene muchas personas realmente inteligentes con gran experiencia, algunas ya tienen títulos y parches calvos. Sin embargo, Jürgen hace sus propios cambios en su código. A veces son pequeñas cosas como agregar espacios, limpiar, etc., pero a veces reescribe el código desde cero mil veces mejor, y al mismo tiempo no cambia la autoría del código, es decir, se compromete bajo el nombre del autor original. En estos casos, se dice que el código fue "legalizado", es decir, lo arregló. Gracias a Jürgen, nuestro código es muy limpio. Para las herramientas de análisis de código, se considera una marca de alta calidad encontrar al menos algún tipo de mal funcionamiento en Spring, porque hay un código muy limpio. En general, no puedo exponer nuestros principios en detalle ahora, pero están allí, fueron establecidos por Jürgen y todos los proyectos de Spring los siguen. En cuanto al Spring Boot, tenemos reglas muy precisas para crear módulos, que llamamos iniciadores.

Ok, gracias por la respuesta. Mi última pregunta será sobre el rendimiento y Java 11. Hasta donde yo sé, Spring siempre genera contexto en tiempo de ejecución. Esto puede llevar de minutos a varias horas en algunos programas bancarios antiguos.

Vamos? No lo creo

Honestamente, visto con mis propios ojos.

Pero no puede ser primavera. Lo más probable es que se haga algo terrible con Hibernate. Los granos se pueden generar en millones, un grano vacío se puede compilar y ejecutar muy rápidamente. Lleva tiempo cargar la información de la base de datos, la validación, etc., esto puede causar que Spring se demore. Pero la primavera misma es muy rápida.

Sí, creo que realmente hubo algún tipo de horror con Hibernate. Sin embargo, Spring comienza 30 segundos, a veces uno o dos minutos, todavía es bastante tiempo, ¿no te parece? Si, por ejemplo, lo ejecutamos en Docker, entonces necesitamos que el contenedor comience de inmediato. ¿Es posible reducir el tiempo de inicio de Spring?

Me toma menos de dos segundos comenzar la primavera. Y con Spring Cloud Function, este tiempo se puede reducir a medio segundo o menos. Tenemos proyectos que se ejecutan sin problemas en medio segundo, por ejemplo, Spring Boot en Spring Cloud Function. Entonces, una vez más, el problema no está en Spring, sino en lo que les haces, lo que sucede en segundo plano: ¿obtienes acceso a otra fuente de datos en Internet, descargas archivos de Internet, cargas datos a la red? . Si todo lo que hace es microservicios pequeños, entonces su sistema debería funcionar muy rápido. Si su aplicación se ejecuta durante mucho tiempo, algo está mal.

Ya veo Por cierto, ¿has oído hablar de GraalVM y AOT?

Si Te diré más: tenemos un proyecto Spring Fu. Él es experimental, grabé un video de la serie Spring Tips sobre él. Lo escribimos en Kotlin, ahora tiene una API Java. Este proyecto fue creado para entornos como GraalVM. Spring Fu no utiliza proxies generados dinámicamente o `@ Configuration`. El generador de imágenes nativas en GraalVM necesita saber qué clases se cargarán. Pero si tiene una carga dinámica usando cglib o Byte Buddy, entonces esto dificulta el uso de GraalVM. Hibernate, Spring y todas las demás bibliotecas que usan proxies generados dinámicamente no son adecuadas para crear una imagen nativa. Por lo tanto, no hay nada como esto en Spring Fu, esto se afirma directamente. Todavía usa Spring, pero el enfoque para crear aplicaciones es diferente. Y una de las ventajas de Spring Fu es que funciona bien con GraalVM. Y ahora la aplicación se inicia al instante. Quiero decir, generalmente al instante: ¡una vez que está completamente en la memoria! Debe recordarse que el generador de imágenes nativas en GraalVM aún se encuentra en una etapa muy temprana de desarrollo. Debido a esto, a veces surgen dificultades, porque a la gente le parece que la aplicación iniciada por GraalVM comenzará a cargarse inmediatamente muy rápidamente, y en tiempo de ejecución la velocidad será la misma que antes. Pero no sucede así, porque en el tiempo de ejecución de GraalVM ya no está utilizando la JVM, el comportamiento del sistema será diferente. Por lo tanto, pruebe este proyecto en busca de salud, pero recuerde que no es una aceleración de lanzamiento gratuito. Y, sin embargo, estoy encantado con GraalVM, su equipo hizo un gran esfuerzo para que funcione mejor con los marcos.

Mi última pregunta, por supuesto, será sobre Java 11.

Si, ella es hermosa.

¿Qué es útil para Spring in it?

Para los desarrolladores de Spring, hay dos criterios principales por los cuales elegimos esta o aquella tecnología: 1. si es adecuada para las necesidades comerciales, 2. si nos conviene como programadores. En cuanto al primer criterio, si esta tecnología proporciona mayor velocidad, estabilidad, si tiene soporte a largo plazo. Todo esto está presente en Java 11. El soporte para Java 8 finalizará pronto, por lo que tiene sentido actualizar a la próxima versión con soporte a largo plazo. Por cierto, mis amigos, si actualizan a la próxima versión, tomen el ensamblaje OpenJDK, es excelente en todos los sentidos. La versión correcta es muy fácil de obtener, ya escribí sobre ella en Twitter. Esta versión funciona muy bien con Spring: es estable. Al menos ahora puede ir a https://start.spring.io , generar un nuevo proyecto, seleccionar Java 11 y funcionará. La compatibilidad con Java 11 está disponible tanto en IntelliJ como en Eclipse.

En cuanto al segundo criterio, no hay cambios significativos para los desarrolladores de Spring en Java 11. Es bueno que aparecieran `var` y el Cliente HTTP, pero Spring ya tenía un Cliente Web reactivo, por lo que no estoy seguro de que nos beneficiaremos del Cliente HTTP. Se agregaron algunas cosas convenientes en Java 10 y Java 9. Además, se hizo posible ejecutar el programa Java como un script; esto no está mal. No estoy seguro de que tenga sentido hacer esto con Spring, aunque, por otro lado, ¿por qué no? Cómo se verá, no lo sé.

¿Fue difícil para Spring cambiar a Java 11?

No En el corazón de Spring hay bibliotecas de muy alta calidad y el ecosistema. Tenga en cuenta que Spring Framework en sí mismo admite classpath y modulepath, pero personalmente no recomiendo usar modulepath. Para usarlo correctamente, todo lo demás también debe admitir modulepath. Y esto aún no es posible, ahora hay muy pocas personas que brinden soporte de modulepath en las bibliotecas. El modo classpath funciona bastante bien. Tuvimos problemas bastante estándar con CGLib, AspectJ y las bibliotecas XML JAXB que todos tenían al cambiar a Java 9. Todos estos problemas se resolvieron aproximadamente el año pasado, lo que nos facilitó la transición a Java 11.

Por cierto, estamos planeando muchas cosas interesantes para futuras versiones de Java, por ejemplo, el proyecto Loom es fibras para Java.

¿Será en Java 12?

Lo más probable es que no lo hagan durante bastante tiempo.

Kotlin también usa corutinas, por lo que este proyecto es muy interesante para nosotros. Cada vez que salga, será de gran beneficio. La capacidad de expresar tuberías reactivas sin crear código reactivo es muy importante. Personalmente, espero con ansias la aparición de cadenas de varias líneas. Tal vez esta no sea la mejor manera de testificarme: tengo un montón de código que requiere una gran cantidad de filas, por ejemplo, consultas SQL y similares.

Esto se debe a que tiene una parte importante del código optimizada para la presentación de diapositivas. En las diapositivas durante los informes, será conveniente mostrar la cadena completa en la pantalla.

Sí, de lo contrario se hace difícil de leer. En el IDE, se verán mucho mejor. Nuevamente, Python, Kotlin, Scala, Groovy: cualquier idioma en los últimos 20 años ha proporcionado soporte de cadenas de varias líneas. En mi opinión, esto es bastante natural.

¿Quizás le gustaría dejar algunos consejos a nuestros lectores? Puede referirse a Spring o Pivotal, y puede referirse a Java en su conjunto.

Como con cualquier tecnología, la mejor parte de Spring es su comunidad. Técnicamente, Spring es un conjunto de proyectos extremadamente interesante, pero el secreto de su longevidad es una comunidad maravillosa. Nadie necesita su maravilloso software si necesita comunicarse con personas insoportables por su bien. Por lo tanto, tratamos de ser lo más amigables posible. Nuestros desarrolladores, incluidos los gerentes de proyectos, responden preguntas sobre Stack Overflow y siguen varias etiquetas allí. Tenemos salas de chat en Gitter, y cada sala de chat corresponde a un repositorio en GitHub. Por ejemplo, https://gitter.im/spring-projects/spring-boot . Allí puede encontrar desarrolladores de Spring y hacer las preguntas que le interesen.

La gente a menudo me pregunta cómo ayudar al proyecto, cómo comenzar a escribir código para Spring. Tenemos muchos problemas con etiquetas como "ideal para contribución" en GitHub. Estamos contentos con todos, pero no todos los proyectos se adaptan a todos, algunos errores son más complicados que otros. Entonces, si quieres trabajar con nosotros, busca estas etiquetas y ayuda con los problemas. Así es como ocurre la reposición de nuestra comunidad. Valoramos el trabajo de todos los que ayudan a mejorar nuestro ecosistema.

Minuto de publicidad. Josh Long llega a la conferencia Joker 2018 con una charla de Reactive Spring . Las entradas se pueden comprar en el sitio web oficial de la conferencia .