Is there a compiler flag to disable auto generated...
# announcements
g
Is there a compiler flag to disable auto generated componentN for data classes?
nope 1
2
n
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.
e
What’s behind the question? What do you use
data
for?
g
@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.
1
g
@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
👍 2
1
a
but in KMM for iOS we got same
componentN
in all dataclasses which exported to swift... and here no any R8 😞
g
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
a
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.
g
@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
g
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
Though, I’m not sure how it will work on Android after dexing with desugaring
g
But it's only JVM 9 😞
g
Right, but isn’t it works only on Java 9+ anyway?
I mean optimized toString
it’s more question to D8/R8 to optimize such cases
g
How can I use this feature if android has java 8
g
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
g
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?
g
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
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”
g
Hm, you mean when d8 sees
invokedynamic StringConcatFactoy.makeConcat
instruction it may replace it with ordinary string concatenation without invokedynamic?
g
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)
g
So that means this feature doesn't make any sense in android
g
I never tried and I don’t know what d8 is doing with such code now