Is there a compiler flag to disable auto generated componentN for data classes?

# announcements

[Grigorii Yurkov]

Is there a compiler flag to disable auto generated componentN for data classes?

[Nicholas Doglio]

Not exactly what you’re looking for but there’s a compiler plugin called Poko which you can use to generate equals, hashCode and toString methods for non-data classes but not any of the componentN stuff.

[elizarov]

What’s behind the question? What do you use data for?

[Grigorii Yurkov]

@elizarov We have tons of data classes in our android project. Almost all classes are DTO. Most of them use data to generate `equals`/`hashcode` others for copy, other just to annotate that this is a class that contains only data, but barely anything for componentN. The problem is data classes generate n component methods, where n is fields count. This grows dex files, because it has 64k limit (by the way our biggest data class has 90!! fields). So I suppose this flag will optimize our big app.

[gildor]

@Grigorii Yurkov R8 should remove all unused componentN
If you do not use R8 I think componentN is not your biggest issue in terms of byte code size

[alex009]

but in KMM for iOS we got same componentN in all dataclasses which exported to swift... and here no any R8 😞

[gildor]

But in case of K/N it’s a part of compiler (there is optimize option), if it not removed for production build it’s probably a bug and should be reported

[alex009]

K/N can't remove it in production build because compiler can't detect is used this componentN functions by swift or not used - deployed only library with all public interface. and for developer experience of iOS developers this componentN functions are bad.

[Grigorii Yurkov]

@gildor yeah, you are right. R8 removes componentN and copy methods. The only problem is hashcode/equals/toString use 50% of data class memory. I would like to know how to replace them with invokedynamic like java does

[gildor]

Ah right, makes sense, it’s always an issue for library code, especially for this case

It really makes sense to do something with it in case of K/N

[gildor]

@Grigorii Yurkov Wouldn’t -Xstring-concat help?
https://kotlinlang.org/docs/whatsnew1420.html#invokedynamic-string-concatenation

[gildor]

Though, I’m not sure how it will work on Android after dexing with desugaring

[Grigorii Yurkov]

But it's only JVM 9 😞

[gildor]

Right, but isn’t it works only on Java 9+ anyway?

[gildor]

I mean optimized toString

[gildor]

it’s more question to D8/R8 to optimize such cases

[Grigorii Yurkov]

How can I use this feature if android has java 8

[gildor]

Well, Android doesn’t has neither Java 8 nor Java 9, it has ART and Dex

D8 supports desugaring of Java 9 bytecode out of the box, just set it as target JDK, but I don’t know what will be result of it after dexing

[Grigorii Yurkov]

I suppose this feature uses StringConcatFactory.makeConcatWithConstants bootstrap method. But it was added in Java 9 and doesn't present in android. I am not following how it suppose to work. Am I wrong?

[gildor]

I suppose this feature uses StringConcatFactory.makeConcatWithConstants bootstrap method

It one of the options, another is makeConcat, but you right, it’s not a part of ART (at least old enough), but your code is passed through D8 anyway, so you can compile it to Java 9, it will use makeConcat, but it will be desugarred by d8 to some dalvik bytecode

[gildor]

It will probably lost this optimization, I agree, my point is that it’s the same with Java “I would like to know how to replace them with invokedynamic like java does”

[Grigorii Yurkov]

Hm, you mean when d8 sees
invokedynamic StringConcatFactoy.makeConcat instruction it may replace it with ordinary string concatenation without invokedynamic?

[gildor]

I think this how it works (except if there is some special optimization for it), all those translations of JVM bytecode to DEX is part of D8 it supports even newer version of JVM, but not all features (all language features, but not all Java standard library additions)

[Grigorii Yurkov]

So that means this feature doesn't make any sense in android

[gildor]

I never tried and I don’t know what d8 is doing with such code now