O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
A Scribd passará a dirigir o SlideShare em 1 de dezembro de 2020A partir desta data, a Scribd passará a gerenciar sua conta do SlideShare e qualquer conteúdo que você possa ter na plataforma. Além disso, serão aplicados os Termos gerais de uso e a Política de Privacidade da Scribd. Se prefira sair da plataforma, por favor, encerre sua conta do SlideShare. Saiba mais.
Janus was the Roman god of beginnings, gates, transitions, time, duality, doorways, passages, and endings. He is usually depicted as having two faces, since he looks to the future and to the past. The Spring community is facing such a duality at this point in particular, catering to a large userbase with existing production systems on legacy infrastructure as versus anticipating architectural trends and the future evolution of the Java ecosystem.
A typical example that strongly indicates current production scenarios is the choice of Java version. According to many recent surveys, Java 8 totally dominates the market six years after its release, despite Java’s new release cadence with a new OpenJDK release every half year. We see the same situation among the Spring userbase, with a strong Java 8 dominance but also a noticeable trend towards Java 11 as the latest long-term support release - and an interest in following the latest OpenJDK releases.
Beyond Java infrastructure generations, there are many other “tensions” in the Spring ecosystem. Enterprise architects in large corporations tend to have a very different mindset compared to software startups working towards a proof-of-concept, not least of it all due to the expected lifetime and the careful evolution of their systems. Corporate servers in data centers are managed very differently compared to cloud hosting. Monolithic systems choose tradeoffs that microservice architectures strongly deviate from.
In the past 16 years that Spring has been serving to support real-world application architectures already, very different configuration styles and architectures have become common: ranging from the XML configuration days to annotation-based configuration, onwards to embedding web servers instead of deploying to application servers, and then recently making configuration very explicit again through functional registration mechanisms - particularly common with (but not limited to) reactive architectures.
Forwarding to 2020 and onwards, OpenJDK has many interesting projects shaping up, from Loom to Valhalla and now Leyden, bringing them to the ecosystem over the next few years through the continuing half-year release cadence, with AdoptOpenJDK - now named Eclipse Adoptium - providing common JDK builds for a wide userbase. And outside of OpenJDK, there’s GraalVM as a key player that challenges our understanding of what the Java platform is these days, not least of it all through native images.
The Java language and the standard APIs slowly but constantly evolve, with the recent introduction of long-awaited features such as text blocks and record classes. The JVM itself evolves even more actively, with virtual threads potentially enabling new kinds of scalable architectures soon. From a Spring perspective, the challenge is to track OpenJDK’s releases, allowing for the evolution of existing Spring applications at their own pace while also enabling new kinds of architectures for newly built systems.
Beyond language features, there are many performance factors: faster startup and reduced memory consumption for short-lived processes, or rather optimizing for peak performance and throughput in a longer-running system? Recent OpenJDK efforts can help here, e.g. Class Data Sharing and the Z and Shenandoah garbage collectors. More dramatically, GraalVM’s native image model provides a radical rethinking for how Java applications can be deployed, to be standardized in OpenJDK’s Project Leyden.
Our upcoming round of releases, in particular Spring Framework 5.3 and the Spring Boot 2.4 release building on it, are designed to bring it all together: supporting the many kinds of existing Spring configuration styles and architectures while also embracing the latest OpenJDK features and providing a path towards native images. Spring Framework 5.3 comes as the last feature release of the 5.x line, while Spring Boot will continue its half-year release iterations based on Framework 5.3.x for the time being.
Looking backwards as well as forwards at the same time, providing a stable foundation for the common architecture styles for years to come, the Spring Framework 5.3 release is an essential step to wrap up the 5.x line. It comes with extended maintenance as known from the 3.2.x and 4.3.x branches, supporting the currently common JDK generations as well as the upcoming JDK 16 and 17 releases in 5.3.x updates next year, leading to a natural upgrade path for all Spring-based systems at their own pace.
Juergen Hoeller at SpringOne 2020
�2020 VMware, Inc.
lienyuan lee / CC BY (https://creativecommons.org/licenses/by/3.0)