Any chance of breaking out the org.json classes from the android_util library?

[adil-hussain-84]

I was revisiting the linker flags in my project today after a long time and I noticed that I'm linking the android_util library but the only classes I'm interested in within the android_utill library are the org.json classes. I was wondering whether it could be possible in future versions of J2ObjC for the org.json classes to be offered as a separate, lighter org_json library?

[tomball]

That's certainly possible, but can't be a high priority since our team is so small. We do accept patch contributions, though (just saying 😉 ).

If you avoid using the -ObjC link flag, only object files in a static library that resolve dependencies in your app will be linked into it. Xcode used to include that flag in new projects, but it's not required and is only necessary to dynamically load classes that are not explicitly referenced by other classes. Because it can link in unused code, -ObjC can increase the app size unnecessarily; a hello-world j2objc app is 2Meg bigger when linked with -ObjC.

Since JUnit tests are dynamically loaded, test apps should always be linked with -ObjC. That's not a size issue, though, since test apps should never be distributed.

If you have an app class that needs to be dynamically loaded, an easy solution is to refer to it using .class in another Java source. Here's an example from sun.security.jca.Providers, that forces the IosSecurityProvider and CertPathProvider classes to be linked:

    @SuppressWarnings("unused")
    private static final Class<?>[] unused = new Class[] {
        IosSecurityProvider.class,
        CertPathProvider.class,
    };

[tomball]

org.json classes are now built to dist/lib/json.jar and lib/libjson.a.

[adil-hussain-84]

Hi @tomball, thank you so much for this change and for the extra information you provided in your response earlier. I've been meaning to come back to this issue and follow through on some of what you said but I've been a little swamped at work and not managed to find the time. Please accept my apologies.

About the -ObjC linker flag: funnily enough, we started revisiting the J2ObjC libraries which we're linking to on the back of an experiment we did to see the implications of changing the iOS framework which we build (which uses J2ObjC) from a dynamic framework to a static framework. We found that when we changed our framework from a dynamic framework to a static framework, any application that consumed our framework had to add the -ObjC linker flag.