1

This question is about byte code level in-lining optimizations that breaks stacktrace and reflection.

I have a library of many static factories to create objects. This class only has static methods such as

public class FruitC {

public static Appple createApple(AppContext ac, AppleParameters...) {
  //stuff using AppContext to create apple use parameters
  return apple;
}

Code calls

FruitC.createApple(AppContext ac, AppleParameters...)

The original idea was to use such a design to allow easy in-lining so that the optimizers could remove the static class completely because after in-lining the class FruitC would be empty.

But you cannot override static methods and you need to pass the Context in parameters to the factory methods and it looks ugly when coding

So the idea now is to create a non static class for each static factory. The non static class is initialized by the Application context

public class FruitFactory { 

private AppContext ac;

public FruitFactory(AppContext ac) {
   this.ac = ac;
}
public Apple createApple(AppleParameters...) {
    return FruitC.createApple(ac, AppleParameters...)
}

This design allows extension if needed. However the default factory can supposedly be inlined and both FruitFactory and FruitC classes removed completely after optimizations.

Is there an optimization tool that will remove FruitFactory and FruitC ?

The smart optimizer must be able to detect that the AppContext is an object whose reference is written ONCE during the app life and then never changes.

Will ProGuard be able to do that?

This optimization must be done at the java byte code level because it must then be sent to Android or another platform.

Mordan
  • 337
  • 3
  • 12
  • The linked Q&A explains that ProGurd can do inlining, and how to enable this for Android. To find out if it actually does what you need, *try it*. If you are asking for about other tools, that is a request for a recommendation, which is Off-Topic. – Stephen C Jan 22 '17 at 02:19
  • The other thing to note is that this level of (micro-) optimization is rarely worth doing. A good JIT compiler should be able to inline code. And recent Android JITs are capable of doing that. (How much effort do you want to spend on supporting old Android phones with poor JIT compilers?) – Stephen C Jan 22 '17 at 02:22
  • I agree. However if I create 100 factory classes whose only job is to forward to a static method designed to be inlined, I want to be certain there is a tool that will do the job. One goal of my framework is to be very lightweigh. – Mordan Jan 23 '17 at 00:41
  • Even 100 factory classes is most likely a tiny (runtime) overhead compared with the rest of the code, the application data, etc. This smells of "premature optimization" to me. And the downside of an inliner is that your build process depends on some 3rd-party (typically) closed-source tool ... which typically means license fees, risk that the vendor stops supporting the feature, problems distributing your source code, etcetera. – Stephen C Jan 23 '17 at 00:59

0 Answers0