hashCode / toString performance issue on fully resolved OpenAPI objects

The recursive hashCode and toString implementation can become very expensive on fully resolved OpenAPI objects. Attached is a sample openapi file of 200KB which bloats to 168MB of string data if you print or log it or check it with a java debugger. The hashcode calculation takes > 300ms which can slow down programs a lot.

I wonder if hashCode really needs to traverse the entire object graph. toString can be optimized a lot if values are stripped.

sample-openapi.zip

        ParseOptions options = new ParseOptions();
        options.setResolveFully(true);
        URL resource = Main.class.getResource("/sample-openapi.yaml");
        SwaggerParseResult result = new OpenAPIParser().readLocation(resource.toExternalForm(), Collections.emptyList(), options);
        OpenAPI openAPI = result.getOpenAPI();

        long start = System.currentTimeMillis();
        System.out.println(openAPI.hashCode());
        System.out.println((System.currentTimeMillis() - start) + "ms");

        FileUtils.writeStringToFile(new File("\tmp\dump.dat"), openAPI.toString());

Start by reproducing the reported timings with the attached sample-openapi.zip and the Java example using ParseOptions.setResolveFully(true). Trace the generated OpenAPI object's hashCode and toString behavior, then compare performance and output size after any change. Done means substantially less hashCode work and toString string data for fully resolved objects without losing required object information.