Slow compile time (probably related to JDK-8152289)

[mvpcortes]

Hi, We have use assertj to a project and the maven project has slow testCompile time now. I see this article about slow compile time for overload and generic in JDKs after 8. And the JDK issues was not fixed.

https://softeng.oicr.on.ca/dusan_andric/2019/08/19/assertJ/

It is true?

I think this problem is not about this library. But I think we can make a best pratices to use to avoid this problem.

Is there anything about this?

Assertj is a greatful assert framework. Thanks for build it :)

Reference: JDK-8152289

[joel-costigliola]

Thanks for the kind words :)

Unfortunately that's not something we can really do something about as we need to use generics and and indeed assertThat is being overloaded a lot but that's by design.
The issue is a compiler issue that should do a better job, I'm curious if that is the case with java 17.

[patrox]

@joel-costigliola We are also facing serious issues with build time duration, as in one project we have ~5 000 unit tests that are heavily using assertJ assertions - as we really like the fluent API and clear messages.

After we migrated from jdk8 to jdk11 the build time has increased significantly, so as a potential solution for that we are considering to move from AssertJ to Hamcrest - as by simply doing a search and replace to reduce the number of AssertJ assertions we were able to reduce the build time for the whole project from 6 minutes to 3 minutes (!).

But we are treating this as a sort of a last resort measure - as like I mentioned us like AssertJ and we would like to keep it, but without sacrificing build times too much. Do you think that there is anything that we can do which would allow us to keep AssertJ and at the same time reduce the build times?

[joel-costigliola]

I wish there is something we can do but I'm not sure we can on AssertJ codebase.
If the root cause is JDK-8152289 then we fix except by removing all generics from AssertJ which we don't want to do.
I'm going to vote for the issue and put reference to this issue hoping it's going to get some attention, maybe vote for it too.
If you have a better idea I'm all ears!

[joel-costigliola]

It does not seem easy to vote or comment on the JDK issue, I have contacted them to see how to be able to.

@patrox have you tried other JDK > 8 to see if the performance is better?

[patrox]

I wish there is something we can do but I'm not sure we can on AssertJ codebase. If the root cause is JDK-8152289 then we fix except by removing all generics from AssertJ which we don't want to do. I'm going to vote for the issue and put reference to this issue hoping it's going to get some attention, maybe vote for it too. If you have a better idea I'm all ears!

I know this JDK issue which you are referencing, but in our case, the performance degradation was observed after moving from jdk8 to jdk11, while the mentioned issue describes a performance degradation which was observed in jdk8 already - so IMO this is not related as we didn't notice any performance issues in jdk8.

FYI, I played with the mentioned example from this bug report and one of ugly hacks to speed it up was to add some type information, so we don't need to rely on JDK:

Before (~50 seconds for the compilation phase):

//100 points
    Graph<Integer> GEO = new Graph<>(
            new Point<>(1),
            new Point<>(2),
            new Point<>(3),
            ...

After (0.5 seconds for the compilation phase):

//100 points
    Graph<Integer> GEO = new Graph<>(
            new Point<Integer>(1),
            new Point<Integer>(2),
            new Point<Integer>(3),
            ...

[patrox]

It does not seem easy to vote or comment on the JDK issue, I have contacted them to see how to be able to.

@patrox have you tried other JDK > 8 to see if the performance is better?

Yes, I tried with JDK 17 and it was comparable to JDK 11.
It's quite a difficult choice for us, as we don't want to stick with JDK8 and in an ideal world we would like to keep AssertJ in the code base, but if that means we need to sacrifice build time, I'm afraid we would go with some other assertion library.

[joel-costigliola]

@patrox you do what you have to do, no hard feelings from the AssertJ team, I wish I had a better answer to this issue but I don't.

[joel-costigliola]

@patrox my last idea: did you try other JDK like amazon coretto, maybe they have better generics compile support ...

[simonis]

In general it is always a great idea to use Amazon Corretto :)

However in this specific situation I'm afraid it won't help, because Amazon Corretto doesn't have any specific changes or improvements compared to the upstream OpenJDK version of the java compiler.