|Summary:||Add proguard rules|
|Component:||POI Overall||Assignee:||POI Developers List <dev>|
Description email@example.com 2019-04-18 19:41:23 UTC
Here is an example set of rules that could be added: https://github.com/square/okhttp/blob/3256f0bddcd58cafbf06cb4ea4bbfe9bdaca2abb/okhttp/src/main/resources/META-INF/proguard/okhttp3.pro Since there's so much reflection, it would be nice if a full set of rules could be developed.
Comment 1 Dominik Stadler 2019-04-23 20:33:52 UTC
I don't know how proguard-rules would apply to Apache POI, why do you think these would be of use here?
Comment 2 firstname.lastname@example.org 2019-04-23 20:43:05 UTC
POI uses reflection everywhere. The team should try running POI with a code shrinker and add rules to keep classes accessed via reflection.
Comment 3 Andreas Beeker 2019-04-23 23:11:22 UTC
In the context of reflections, I don't understand why code shrinking would give us any benefit. If a user wants to hide the fact, that they are using POI, they can obfuscate their project including POIs source. But for the sake of debugging, I wouldn't release optimized code. Furthermore I assume, that we have performance/memory problems because of holding a lot of XML based document data ... optimizing only the calls to the XmlBeans API won't make much of a difference. So if we would use it in a temporary step, how would it help us with fixing reflection based problems? As you seem to be familiar with proguard, how did it help you, to find bugs in your project or POI itself?
Comment 4 email@example.com 2019-04-24 02:54:47 UTC
Ah, sorry for the misunderstanding. I'm not asking for POI to be proguarded before it's released (that's gross). Instead, I'm asking that a set of proguard rules for library consumers be maintained. That is, I shouldn't have to guess at what rules I need if I want to minify my product before release. Does that make sense?