i've been interested in this issue since I first reported it, so i thought i'd say a few things on the matter.
> We may be able to resolve a long-running performance issue we have had with newer versions of Groovy. Ken undersells this. This issue has been a blocker for over two years when I first reported it to the Groovy Community and didn't get much (any) traction in collaborating to a fix. Ken managed to profile and dig his way through Groovy code to further isolate the issue and even managed to cast the problem in a way to get the Groovy Community to engage on a solution. > A quick test showed that the time could be reduced from 90 minutes to 25 minutes One of the biggest pain points for release managers is doc publishing. On newer versions of Groovy without his changes doc generation would have easily been over a full 24 hours. It's great to hear that impossible slowness is avoided but that existing doc generation speeds up considerably for future release managers. Nice work Ken! On Wed, Mar 1, 2023 at 6:16 PM Ken Hu <k...@bitquilltech.com.invalid> wrote: > Hi Everyone, > > I just thought I would leave a quick message about the state of some of our > Java dependencies. > We may be able to resolve a long-running performance issue we have had with > newer versions of > Groovy. The change for this is currently in review in PR1983. This change > will allow us to run > process-docs.sh much faster than before. A quick test showed that the time > could be reduced from > 90 minutes to 25 minutes. Once this gets merged, then it should unblock us > from upgrading Groovy. > The current plan is to upgrade to Groovy 4.0.9 on the master branch and to > upgrade to Groovy 2.5.21 > on 3.5-dev and 3.6-dev. > > Once we upgrade Groovy, we can then focus on building and testing with JDK > 17 on the master branch > as Groovy was the major blocker in upgrading the runtime version. There are > other libraries that > will potentially need upgrading such as Spark and Kryo. See TINKERPOP-2703 > for the work that > Stephen has already done for this. Upgrading to Kyro 5.x will likely cause > breaking changes for > those that use Kyro 3.x as the two formats aren't compatible. However, it > seems like we have mostly > deprecated the use of Kyro already so this should reduce its impact. > > To summarize, there will be major version upgrades coming to several Java > libraries (Groovy and Kyro > in particular) in the master branch. This should enable us to run and build > with JDK 17 on master. > > Thanks, > Ken >
