zakkak
commented
3 years ago A possible implementation would Substitute all reachable classes matching the pattern passed to --exclude and it would also Substitute all reachable methods of those classes to throw an exception.
For instance, the following program:
import javax.imageio.ImageIO;
import java.io.File;
import java.io.IOException;
public class AWT {
public static void main(String[] args) {
try {
ImageIO.read(new File("myfile.jpeg"));
} catch (IOException e) {
//
}
}
} when compiled with --exclude=javax.imageio.ImageIO should generate the equivalent to the native image generated by compiling the following code:
import javax.imageio.ImageIO;
import java.io.File;
import java.io.IOException;
import java.awt.image.BufferedImage;
import com.oracle.svm.core.annotate.*;
public class AWT {
public static void main(String[] args) {
try {
ImageIO.read(new File("myfile.jpeg"));
} catch (IOException e) {
//
}
}
}
@Substitute //
@TargetClass(className = "javax.imageio.ImageIO")
final class Target_javax_imageio_ImageIO {
@Substitute
public static BufferedImage read(File input) throws IOException {
throw new UnsupportedOperationException("javax.imageio.ImageIO has been excluded from this native-image please recompile without excluding it");
}
}
borkdude
ppalaga
fniephaus
vjovanov
Skater901
Feature request
Add the option to explicitly exclude packages/classes from native images.
Is your feature request related to a problem? Please describe.
With the recent release of GraalVM 21.0 we came across https://github.com/quarkusio/quarkus/issues/14972. The culprit of this issue is that although an application may never use some reachable (based on the static analysis) code, the code still gets baked in the native image and in some cases also requires it to be linked against extra libraries.
What we observed is that when using JAX-B the native-image brings in a number of classes from
javax.imageio,java.awt,sun.java2d, etc. even though the application may not actually use them. The cause seems to be the class initialization of RuntimeBuiltinLeafInfoImpl which essentially enables JAX-B to process images, something that an application may have no interest in.Enabling users to exclude specific packages/classes that they know a priori that their application doesn't rely on can have the following benefits:
Describe the solution you'd like.
An option to explicitly exclude specific packages/classes from the native image, something like
--exclude=java.awt.**.The exclusion should ensure that:
sun.java2d.cmm.lcmsis excludedDescribe who do you think will benefit the most. GraalVM users, and developers of libraries and frameworks which depend on GraalVM.
Describe alternatives you've considered. The current way to work around such issues is to substitute the methods and fields that cause the undesirable classes to be reached. Unfortunately though in the case of JAX-B this seems impossible (happy to be corrected) since the method that needs to be substituted is the class initializer itself, and even if there was a way to substitute it, it would require duplicating a vast amount of code.
Express whether you'd like to help contributing this feature I am willing to contribute and I would appreciate some guidance.