This is awesome James! It will help to issue the feeling I described to you when demoing Grails to new users.
Em seg., 5 de out. de 2026 às 23:59, James Daugherty via dev < [email protected]> escreveu: > 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 > > > -- *Henrique Lobo Weissmann* Diretor Técnico - itexto Telefone / WhatsApp - +55 31 9 9226 0459 https://itexto.com.br
