Reduce jar size by using abstract classes

[joroKr21]

Traits generate bridge methods in every subclass

See #4750

main, 2.12
- JVM:     6.1MB jar, 23.6MB uncompressed, 28.8MB on disk
- JS:     10.9MB jar, 38.1MB uncompressed, 49.4MB on disk
- Native: 12.4MB jar, 39.7MB uncompressed, 58.2MB on disk

main, 2.13
- JVM:     6.4MB jar, 24.3MB uncompressed, 29.6MB on disk
- JS:     11.3MB jar, 39.2MB uncompressed, 50.7MB on disk
- Native: 12.8MB jar, 40.9MB uncompressed, 59.7MB on disk

main, 3.3
- JVM:     7.1MB jar, 23.8MB uncompressed, 31.6MB on disk
- JS:     11.8MB jar, 37.5MB uncompressed, 51.5MB on disk
- Native: 13.4MB jar, 39.9MB uncompressed, 61.4MB on disk

abstract-classes, 2.12
- JVM:     5.1MB jar, 15.3MB uncompressed, 20.6MB on disk
- JS:      8.9MB jar, 24.8MB uncompressed, 36.2MB on disk
- Native: 10.5MB jar, 26.3MB uncompressed, 44.8MB on disk

abstract-classes, 2.13
- JVM:     5.3MB jar, 15.8MB uncompressed, 21.0MB on disk
- JS:      9.1MB jar, 25.4MB uncompressed, 36.9MB on disk
- Native: 10.8MB jar, 26.9MB uncompressed, 45.8MB on disk

abstract-classes, 3.3
- JVM:     6.2MB jar, 16.2MB uncompressed, 23.9MB on disk
- JS:      9.9MB jar, 25.0MB uncompressed, 39.0MB on disk
- Native: 11.6MB jar, 26.9MB uncompressed, 48.3MB on disk

[johnynek]

Can you add to the PR how the uncompressed jar size changes after this please?

Thanks for doing this.

[joroKr21]

I updated the description with sizes

[joroKr21]

Biggest offenders remaining (can't fix because they are static methods and binary compatibility):

457K Jan  1  2010 implicits.class
371K Jan  1  2010 SemigroupalArityFunctions.class
158K Jan  1  2010 Semigroupal$.class
153K Jan  1  2010 ApplyArityFunctions.class
150K Jan  1  2010 InvariantSemigroupal$.class
150K Jan  1  2010 ContravariantSemigroupal$.class
150K Jan  1  2010 ContravariantMonoidal$.class
125K Jan  1  2010 ParallelArityFunctions.class
123K Jan  1  2010 implicits$.class
121K Jan  1  2010 Semigroupal.class
117K Jan  1  2010 ContravariantMonoidal.class
116K Jan  1  2010 ContravariantSemigroupal.class
116K Jan  1  2010 InvariantSemigroupal.class
100K Jan  1  2010 ParallelArityFunctions2.class
103K Jan  1  2010 AllSyntaxBinCompat.class
475K Jan  1  2010 AbstractTupleInstances.class

[satorg]

@joroKr21 ,

Biggest offenders remaining

Yet a substantial decrease in sizes is achieved, thank you!

May I suggest the below representation of the size comparisons for nicer visualisation?

Details

	main (jar)	abstract classes (jar)	main (uncompressed)	abstract classes (uncompressed)	main (disc)	abstract classes (disc)
JVM 2.12	6.1MB	5.1MB	23.6MB	15.3MB	28.8MB	20.6MB
JVM 2.13	6.4MB	5.3MB	24.3MB	15.8MB	29.6MB	21.0MB
JVM 3.3	7.1MB	6.2MB	23.8MB	16.2MB	31.6MB	23.9MB
JS 2.12	10.9MB	8.9MB	38.1MB	24.8MB	49.4MB	36.2MB
JS 2.13	11.3MB	9.1MB	39.2MB	25.4MB	50.7MB	36.9MB
JS 3.3	11.8MB	9.9MB	37.5MB	25.0MB	51.5MB	39.0MB
Native 2.12	12.4MB	10.5MB	39.7MB	26.3MB	58.2MB	44.8MB
Native 2.13	12.8MB	10.8MB	40.9MB	26.9MB	59.7MB	45.8MB
Native 3.3	13.4MB	11.6MB	39.9MB	26.9MB	61.4MB	48.3MB

(generated from your data with help of Github Copilot)

[satorg]

Hi @joroKr21 , thank you again for this incredible work!
I'm going to put aside some time to wrap my head around this PR.

Meanwhile, would you mind updating your branch to the current state of the repository if you have time please?

[satorg]

I've looked through as thoroughly as I could and I have to say it is a tremendous and valuable work! Thank you for nailing it!

[satorg]

@joroKr21 , thank you for keeping it up-to-date!

I'm not sure if we should wait for the second approve, to be honest.
From my perspective, the PR is ready to go.
But since it is a pretty big one, I'd prefer that someone else would take another look.

[bpholt]

This seems like a definite win! Could you note for the record why this is binary compatible? i.e. why it's not a problem that those bridge methods are no longer there?

[joroKr21]

This seems like a definite win! Could you note for the record why this is binary compatible? i.e. why it's not a problem that those bridge methods are no longer there?

The bridge methods are still there, just inherited from the abstract class (and defined only once instead of N times).

[satorg]

Hello team,
Sorry for the ping.

I'd really appreciate if we could move forward with this PR.
There is quite a bit of changes in the PR, so it can begin to interfere with other contributions to the repo.

Thank you!

[satorg]

Hi @armanbilge @johnynek @LukaJCB, or any other maintainer who is around.

I'd personally go with merging this PR, unless you have any objections.
Let me know please if you'd like to take a look too, but haven't got a chance yet.
Feel free to ignore if you are ok with my review.

Sorry for the ping again, but since this is a rather hefty one, I'd like to double-check that we are all on the same page.
Thank you!

[johnynek]

Looks good to me. The win seems valuable enough. We should keep an eye on this in the future if we ever do more codegen (although with scala3 maybe that's a thing of the past).

[LukaJCB]

LGTM!

[satorg]

Thanks everyone!

[joroKr21]

Hmm, do we publish snapshots?

[armanbilge]

@joroKr21 yes, the information is output during CI:

https://github.com/typelevel/cats/actions/runs/23520949757/attempts/1#summary-68465073798