You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
publicclassMain {
interfaceCommon {
voidfoo();
}
staticclassImpl1implementsCommon {
@Overridepublicvoidfoo() {
}
}
staticclassImpl2implementsCommon {
@Overridepublicvoidfoo() {
// 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.newbuild.init.UnsafeClass();
}
publicvoidsomething() {
}
}
staticCommoninstantiate() {
// Impl2 is instantiated, but the foo method is not called and the instance does not escape this method.Impl2impl2 = newImpl2();
impl2.something();
returnnewImpl1();
}
publicstaticvoidmain(String[] args) {
Commoncommon = instantiate();
common.foo();
}
}
The text was updated successfully, but these errors were encountered:
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>
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.
The text was updated successfully, but these errors were encountered: