This is because calling JsonSchemaConfig.builder() automatically sets the SubclassesResolver(null) and which in turn trigger the entire classpath scan to build class graph, such
public SubclassesResolver(ClassGraph classGraph) {
if (classGraph == null) {
log.debug("Entire classpath will be scanned because SubclassesResolver is not configured. See https://github.com/mbknor/mbknor-jackson-jsonSchema#subclass-resolving-using-reflection");
classGraph = new ClassGraph();
}
this.scanResult = classGraph.enableClassInfo().scan();
}
This is prob the side effect on generated code from scala to java - but I haven't dig deeper
This takes up a lot of memory and is a waste of resources esp. if we are specifying the packages/classes to scan. In the code below, we are already scanning the entire classpath at JsonSchemaConfig.builder() before setting limiting the packages to scan subclassesResolver(..) e.g
val config = JsonSchemaConfig.builder()
.subclassesResolver(SubclassesResolver(listOf(ENTITY_PACKAGES_TO_SCAN), listOf()))
.....
.build()```
This is because calling
JsonSchemaConfig.builder()
automatically sets theSubclassesResolver(null)
and which in turn trigger the entire classpath scan to build class graph, suchThis is prob the side effect on generated code from scala to java - but I haven't dig deeper
This takes up a lot of memory and is a waste of resources esp. if we are specifying the packages/classes to scan. In the code below, we are already scanning the entire classpath at
JsonSchemaConfig.builder()
before setting limiting the packages to scansubclassesResolver(..)
e.g