Platform Core: Azul Zulu Builds of OpenJDK

My main use case for Azul Zulu in the current project is developing the archiving and unarchiving system. I use Azul Zulu on the back end when I created a REST API, which I use together with Java Spring Boot and the libraries. I do everything through the IDE, so I use it to build, together with OpenAPI, my REST API.

Azul Zulu has had a positive impact on my organization because I am new to the company and they asked me to develop with recent technologies. They use pure Java, without Spring, and when I brought the solution, they liked it a lot, mainly because of the speed at which the project started to be delivered.

I have noticed measurable results after adopting Azul Zulu. I joined this project which had already been underway for approximately six months, and in two months, I refactored the whole project and wrote it, and it is functional. During the six months that the project was in the hands of another developer and with another technology, the project practically did not move. Then with the adoption, in two months, the project moved forward significantly.

In my opinion, the best features that Azul Zulu offers are speed, as today we need to develop applications very quickly, and the speed that it allows us to implement is what helps me.

Regarding speed, it is not specifically one feature but the whole set of features that benefits us. Sometimes I have worked on other projects with Java that took time, and some things are not automatic. Processes that are automated and files that are generated by the IDE or by the CLI itself help a lot in development instead of having to build thousands of lines of code that, theoretically, are generated by a command. It already comes ready.

I think Azul Zulu can be improved by always thinking about productivity, as most languages tend to evolve in that direction. I have two projects that I am working on in parallel, one using Angular 21 and the other using Angular 22. If I use CLI commands in Angular 21, it will build the files with the extension; for example, it will create dot component. If I use it in Angular 22, it no longer creates that. Developers noticed that this was a performance gain in terms of visualization. Everyone already knows that is a component. The same applies to Azul Zulu. Developers have to observe the development community a lot and have an open channel for improvements so they can enhance the way developers create, not just thinking about the final product. The final product is extremely important, obviously, but for construction, developers have to be prepared for that technology and understand that it is easier for them, that it speeds up the work. If you simply put something in, and that feature you added is not applicable, the developer will not use it, making it unnecessary work.

I have been using Azul Zulu for about two years.

Azul Zulu is stable in my experience so far.

The scalability of Azul Zulu in my experience seems easy and fast, though that belongs to another department.

Azul Zulu's customer support is not handled by me.

I used a different solution before Azul Zulu, and I changed because it was requested. As a developer, they requested that a specific stack be used, and that is what I did.

My experience with Azul Zulu's pricing, setup costs, and licensing is that all of that was handled internally. It was not done with me, as I am just the developer and do not have access.

I cannot present any return on investment metrics with Azul Zulu because it is not my department. The company I work for is a public agency, so that is not available to me either.

I did not evaluate other options before choosing Azul Zulu.

My advice to others who are thinking about using Azul Zulu is to try to explore as much as possible what it offers, getting away from the conventional paradigm. I would rate this review as a nine out of ten.