Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include All Mode for Native Image #3998

Closed
d-kozak opened this issue Nov 8, 2021 · 1 comment
Closed

Include All Mode for Native Image #3998

d-kozak opened this issue Nov 8, 2021 · 1 comment

Comments

@d-kozak
Copy link
Contributor

d-kozak commented Nov 8, 2021

Create a mode where all user code is included in the image, so that any configuration errors that might be dependent on the reachability of some type become visible. The goal is to allow developers to check even those parts of their applications that are not included at the moment to see whether they are native-image compliant and their configuration is valid. Switching from a more precise to less precise analysis could make these errors visible (because more types might be marked reachable), which would seem like a bug in the analysis, even though it is a configuration error that has already been there.

Is your feature request related to a problem? Please describe.
Since the images built by Native Image only include what is considered reachable by static analysis, configuration errors on unreachable classes won't be reported. This situation might arise for example when a specific package is marked for build time initialization. If such a package contains a class that is not suitable for build time initialization (e.g. because it keeps a reference to a started thread), the error will be reported only if the class is reachable. Such an error can be hidden for a long time until that class becomes reachable somehow. Having a mode where all classes are reachable would help to discover this class of errors immediately.

Example
In the following code, the configuration error related to class initialization error might or might not be reported depending on whether the method Impl2.foo is considered reachable - in this particular case it should not, because it won't be called in a real execution, however, a less precise analysis could consider it reachable.

public class Main {

    interface Common {
        void foo();
    }

    static class Impl1 implements Common {
        @Override
        public void foo() {
        }
    }

    static class Impl2 implements Common {
        @Override
        public void foo() {
            // Assume that the UnsafeClass in not safe for build time initialization,
            // but it is in a package that is configured to be initialized at build time.
            // The error will be reported only if this method (Impl2.foo) is reachable
            // which depends on the precision of the analysis.
            new build.init.UnsafeClass();
        }

        public void something() {

        }
    }

    static Common instantiate() {
        // Impl2 is instantiated, but the foo method is not called and the instance does not escape this method.
        Impl2 impl2 = new Impl2();
        impl2.something();
        return new Impl1();
    }

    public static void main(String[] args) {
        Common common = instantiate();
        common.foo();
    }
}
@vjovanov
Copy link
Member

This ticket has been subsumed by the flags that were introduce with Layered Native Images. The flags that can be used to serve this functionality are -H:IncludeAllFromModule=<module> and -H:IncludeAllFromPath=<class-path-entry>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants