[MSHADE-205] Better use of ClazzpathUnit for improved jar minimization

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.4.1
• Fix Version/s: 2.4.2
• Assignee: Karl Heinz Marbaise
• Reporter: Benoit Perrot
• Created: 28/Sep/15 11:25
• Updated: 28/Sep/15 12:04
• Resolved: 28/Sep/15 12:04

Description

Minimizing an uber-jar consists in assessing the relevance of classes of all artifacts on which the project being processed depends: when a class is not identified as being used, it is simply removed from the final jar.

To support implicit uses (e.g. dynamically loaded classes), it is possible to explicitly tell the maven-shade-plugin that a classes must be specifically included.

The algorithm for assessing the relevance of these classes is roughly the following:

// All classes are initially considered as irrelevant
for each artifact in dependencies:
  for each class in the set of irrelevant ones:
    if artifact contains class && class is specifically included:
      remove class from the set of irrelevant ones

Checking whether an artifact contains a class or not is done by invoking the getClazzes() method on org.vafer.jdependency ClazzpathUnit. Contrary to what its name suggests, this method is not as harmless as it seems: it actually builds a hash set and fills it up with the entire set of classes in a given jar each time it is called. (See ClazzpathUnit.java, line 36 at the time of writing)

The instance of ClazzpathUnit is not modified during the iteration, so simply caching the result of this getClazzes() would avoid the creation and filling of the said set, and greatly increase the speed of the process.

The improvement obviously depends on the number of artifacts used by the project being processed, and the number of classes inside them. We observed very significant gains on our industrial cases.