Hi James, about the distribution, this only happens on the first time we start Grails. Sometimes it takes A LOT of time, which may cause a bad first impression for new comers. I have this experience really often when demoing Grails for the first time on some presentations I do.
I remember that in Grails 1.x (and I think 2.x also) we had a lot of dependencies which came preloaded on the framework on the lib folder, so it was (my memories may be wrong) really quick to start working: but those were older times when broadband Internet was not so common. Em seg., 5 de out. de 2026 às 11:45, James Daugherty via dev < [email protected]> escreveu: > I intend to respond to the actual question of this thread in a separate > reply, but to respond to Henrique on performance ... > > Work has already started on improving the start up time, Grails 8 is > delivering numerous improvements here: > 1. parallel bean initialization - we have to ditch bean overriding to do > this. Grails 8 is the first release working toward this and I think the > majority have been addressed. Once we split our dependencies out better, > we can start making use of `@Bean(bootstrap = BACKGROUND)` > > https://medium.com/@semitaho/boost-spring-startup-speed-background-bean-initialization-in-spring-6-2-47c56d813521 > seems to give a reasonable summary of this. This will be huge when we can > switch to this. Your work will scale with your processor at this point. > 2. compile time optimizations - we started generating "indexes" of compile > time data already in Grails 8. Taglibs are a good example here. We have > current plans to bring this across the application - url mappings, etc. > All of the runtime based calculations can then be compile time based and > will be a significant application boost (not just startup) > 3. gradle improvements - I started in Grails 7 rewriting a large portion of > the Grails Build & Gradle code. We have continued that work gradually, but > eventually the Grails Gradle Plugin will be fully lazy with no > afterEvaluate calls & support the configuration cache. As we begin to > adopt more caching features of Gradle, steps will run less, which means the > time goes to zero for values not changed. This affects multi-project > builds the most. If you used Grails 6 and went to Grails 7, you should have > already noticed this benefit when running tests as most of my work > prevented unneeded reruns of tasks. > 4. multi project builds - I've argued for a while now that we should have > better tooling to support multi-project builds. I'd go further to say that > most Grails projects, or at least ones of any significant size, should be > multi project builds. Gradle's support for incremental groovy compilation > is not great and hasn't improved, but its support for multi-project builds > is. On large code bases, splitting your code into separate projects > significantly impacts the performance of application start up. If your > actual app has 10 base projects instead of one monolith, think of it this > way: no changes to those 10 base projects means no recompilation, > processing of assets, etc. > 5. better support for AOT / CRaC (https://openjdk.org/projects/crac/) / > Native - Scott has already been contributing numerous changes to support > these technologies. As they are adopted in Grails, you should see > significant performance benefits on startup. Project Leyden ( > https://openjdk.org/projects/leyden/) is the upstream Java project focused > on this problem. > 6. I'm sure I've forgotten others, but these were the ones I could think of > off the top of my head. > > Concerning the distribution, the first download of dependencies will likely > always be slow since they are downloaded & pulled into the Gradle cache on > the first pull. Every pull after that shouldn't be slow though since it's > cached locally. I've never had anyone raise this as a concern, and I'm > interested to know if this is a "first time" issue or an ongoing issue. > > -James > > > On Mon, Oct 5, 2026 at 9:49 AM Henrique Lobo Weissmann <[email protected] > > > wrote: > > > I think this is a good idea James, specially if Groovy 6 could bring > > improved startup times (specially on development mode). One of the main > > issues while showing Grails to new users is the startup time on > development > > mode on the CLI. > > > > Going further James, I have a suggestion: is there anything we could do > to > > improve this startup time on development mode, maybe provide more libs on > > the Grails distribution to avoid the fetch of these dependencies from the > > Internet? > > > > Em dom., 4 de out. de 2026 às 22:04, James Fredley < > > [email protected]> > > escreveu: > > > > > Hi everyone, > > > > > > The 8.0.0 vote is out, which is is an AWESOME accomplishment. > > > > > > While that finishes, I want to discuss what we do next, before we spend > > > time on the wrong branch. > > > > > > Proposal: do not release an 8.1.x on Spring Boot 4.2 in Q1 2027. Ship > > > 8.0.x, move straight to 9.0.x on Groovy 6 (snapshots already exist), > and > > > pick up Spring Boot 4.2 in a 9.1.x release after that GA is out. > > > > > > The schedule would look like this: > > > > > > - 8.0.0 on Spring Boot 4.1 and Groovy 5 - now > > > - 9.0.0 on Spring Boot 4.1 and Groovy 6 targets late November or early > > > December. Those snapshots are already running. > > > - I expect Spring Boot 4.2 GA around Christmas or early January rather > > > than the usual late November window. 4.1 landed in June, about a month > > > late. Spring Boot 4.2.0-M2 shipped on 24 September. The 4.2.0-RC1 > > > milestone is 29 of 30 issues closed > > > (https://github.com/spring-projects/spring-boot/milestone/433). The > > > 4.2.0 GA milestone is open, but Spring has not set a due date > > > (https://github.com/spring-projects/spring-boot/milestone/434). > > > - After Spring Boot 4.2 GA, we release 9.1 on top of 9.0 in Q1 2027 > > > - 8.1 stays on the shelf unless we find a real reason to release it. > > > > > > Two release trains are driving this. We still cut a Grails major when > > > Spring Boot cuts a major. Groovy now looks like it will cut a major > > > about once a year, and that will also be a Grails major. I do not think > > > we should also keep chasing each Spring Boot minor on the old Groovy > > > line. Cleaner cutoff: a Grails line stays on the Spring Boot minor it > > > shipped with, and the next Spring Boot minor lands on the new Groovy > > major. > > > > > > The merge cost is the main reason to skip an 8.1 release. Spring Boot > > > 4.2 changes will not apply cleanly to the Groovy 6 work already on > > > 9.0.x. They will apply to 9.1, which is where we want them. Doing that > > > upgrade for an 8.1 release and again for 9.1 is the same work twice. > > > Those changes might get merged to the wrong line, replayed, or dropped. > > > We could try to keep lines working on both Spring Boot 4.1 (Grails > 8.0.x > > > and 9.0.x) and 4.2(Grails 8.1.x and 9.1.x), but that is not worth it > for > > > a line most people will leave quickly or skip entirely. > > > > > > 9.0 should be a short release. If it lands in late November or early > > > December, 9.1 can follow soon after the Spring Boot 4.2 GA in Q1 2027. > > > Users will likely move to latest Groovy, especially with the > performance > > > boost. > > > > > > This does not end 8.0.x. Patch releases on 8.0.x continue as usual. The > > > only question is whether we spend a minor release moving Groovy 5 onto > > > Spring Boot 4.2. > > > > > > Does this match what others expect for the next few months? > > > > > > Reasons that would change my mind: users who cannot move to Groovy 6, a > > > compatibility promise we have already made, or a merge approach that is > > > cheaper than it looks. > > > > > > Thanks, > > > James Fredley > > > VP, Apache Grails > > > PMC Chair > > > > > > > > > -- > > *Henrique Lobo Weissmann* > > Diretor Técnico - itexto > > Telefone / WhatsApp - +55 31 9 9226 0459 > > > > https://itexto.com.br > > > -- *Henrique Lobo Weissmann* Diretor Técnico - itexto Telefone / WhatsApp - +55 31 9 9226 0459 https://itexto.com.br
