[jboss-jira] [JBoss JIRA] (JGRP-2155) Weight loss program

Yves Cuillerdier (JIRA) issues at jboss.org
Mon Jan 30 04:31:00 EST 2017


    [ https://issues.jboss.org/browse/JGRP-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13354681#comment-13354681 ] 

Yves Cuillerdier commented on JGRP-2155:
----------------------------------------

Hi,
even if it is 2.5mb, i face the problem because Android limits the APK size.

Removing class if not so easy. It is a try & fail tedious process because of the two main configuration files, the class instantiation by reflexion and all the dependencies. 

It is not at all a performance concern as i beleave that this point is governed by the protocol exchange.

Another point is related to the security:

I have not look this point deep, but i realized that knowing the connect name is enought to communicate with a JGroups instance. As all protocols are present, it may be easy for anyone to send commands. So i think it is important to limits the class to the minimum needed by the project configuration.

As you still widely use the Annotations i think this may be the easiest way but you can do it as you will.

Anyway, i think that you should move the demo and test packages to comply with maven recommendations.

While i am here, can i ask you to use the sl4j framework and leave the logging choice to the user? This will also save the logging package.

Thanks a lot for your work. It saved me a lot of sweat.

Yves

> Weight loss program
> -------------------
>
>                 Key: JGRP-2155
>                 URL: https://issues.jboss.org/browse/JGRP-2155
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Yves Cuillerdier
>            Assignee: Bela Ban
>
> JGroups jar is quite large and it is sometime desirable to shrink it some way.
> Currently the jar contains unnecessary class (demo, test and perf) and it is not possible to keep the only needed protocols using tools like Proguard (it's like having a server with all ports open).
> My suggestions are:
> h2. Move JGroups' side class
> Demo: Move the {{demo}} package to a maven module.
> Test and perf: Move the test package to the maven test source and generate test-source jars.
> Note that the {{MPerf$MPerfHeader}} must be removed from the {{jg-magic-map.xml}} file.
> h2. 
> h2. Make JGroups Proguard compatible
> A classical way to shrink and optimize project is to use the *{{Proguard }}*tools.
> This tool cannot be used for JGroups mainly because of the two configuration files {{jg-magic-map.xml}} and {{jg-protocol-ids.xml}}.
> These two files contain all class files for all possible protocols, even those that are not required by the selected configuration for the project (for example, using {{fast.xml}} does not require {{ENCRYPT}}, {{TUNNEL}} and many more.)
> The problem is that Proguard could not understand these two files and removes all class because there is no entry points.
> One way to solve this may be to create Annotation (for example {{@MagicMap}} and {{@ProtocolIds}}) and remove the two files. These annotations could be searched by the initialization process in the class maintained by the Proguard tools. This should not affect the loading time as all relevant class are in the same package {{org.jgroups.protocols}}.
> This is not enough because some fields are initialized by reflection using hard coded name (for example "{{bind_add}}"). For such fields we need an Annotation like {{@KeepField}} to tell Proguard not to optimize, remove or rename the fields. For example:
> -keepclassmembers class * { @jgroups.annotations.KeepField <fields>; }
> This Annotation may also be used for class where instance are created by reflection (like {{GMS.GmsHeader}}).
> Last we need to specify the entry points for the project configuration else Proguard will still remove all. The xml configuration files (like {{fast.xml}}) should be kept to provide the protocols configuration. 
> This is a matter of the Proguard configuration file. For example in a project using{{ fast.xml}}, we should have:
> -keep public class org.jgroups.protocols.UDP.** { *; } 
> -keep public class org.jgroups.protocols.PING.** { *; } 
> -keep public class org.jgroups.protocols.MERGE3.** { *; } 
> -keep public class org.jgroups.protocols.FD_SOCK.** { *; } 
> -keep public class org.jgroups.protocols.FD_ALL.** { *; } 
> -keep public class org.jgroups.protocols.VERIFY_SUSPECT.** { *; } 
> -keep public class org.jgroups.protocols.BARRIER.** { *; } 
> -keep public class org.jgroups.protocols.pbcast.NAKACK2.** { *; } 
> ... etc
> My 2 cents.
> Yves



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


More information about the jboss-jira mailing list