Hi Henrique, While I can't address Gradle's initial, large download of dependencies, I think we can make the dev server "feel" faster and make it more apparent when something is causing a slow start. I've opened https://github.com/apache/grails-core/pull/16536 as a way to immediately launch a server that responds on the server port with a progress bar that's shown until the application starts up. It will be a useful development tool to make people aware of why their startup is taking so long. It's extensible and by default the db migration plugins contribute their status to the progress so long running migrations can be easily determined. This is obviously only meant to be used in development at this time, but technically it could run in any environment.
-James On Mon, Oct 5, 2026 at 11:15 AM Henrique Lobo Weissmann <[email protected]> wrote: > 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 >
