Add itext core metadata and tests

[vitali-pr]

What does this PR do?

Add itext core metadata and tests

Code sections where the PR accesses files, network, docker or some external service

Checklist before merging

• I have considered including reachability metadata directly in the library or the framework (see our contributing document)
• I am the original author of all content provided in the pull request, and I did not copy the content from any other source (see the tests section from our contributing document)
• For all tests where I am not the sole author, I have added a comment that proves I may publish them under the specified license (see the tests section from our contributing document)
• I have properly formatted metadata files (see our formatting guide)
• I have added thorough tests (see the tests section from our contributing document)
• I have filled all places where my pull request accesses files, network, docker, or any other external service (see the section above)

[vitali-pr]

Hi @olpaw ,
Somewhere in another PR I saw that it's ok to ping you if the PR is not processed for quite some time.
It's been a while since this PR created. Is there a chance you have a look at it? Thanks!

[olpaw]

Hi @vitali-pr

Thanks for the reminder. This got lost in the sea of emails. I will have a look this week.

[olpaw]

Use either

"latest": true,

or

"default-for": "8\\.0\\..*"

Using them both makes the "default-for" irrelevant thus potentially confusing.

Same for other index.json files in your PR.

See https://github.com/oracle/graalvm-reachability-metadata/blob/master/CONTRIBUTING.md

Since 8.x.y is really the latest and you do not have metadata for older versions I suggest you just remove all the "default-for" ... entries in your index.json files.

[vitali-pr]

Pushed the required changes amended with the initial commit.

[olpaw]

This PR looks clean. Only thing that needs to be changed before merging is to remove the unnecessary use of "default-for": ... as already mentioned in #470 (comment)

[vitali-pr]

@olpaw , I see the failed checks. I didn't add conditions for those io resources intentionally. This is how we use them on java. They are coming with a (separate) font-asian jar. If it's in class path, they are available for a user to load.

[olpaw]

This is how we use them on java. They are coming with a (separate) font-asian jar. If it's in class path, they are available for a user to load.

So there are no class files in font-asian jar that you could use as typeReachable?

Even if so ... it should be fine to use

      "typeReachable": "com.itextpdf.io.font.Type1Font"

even for the resources in font-asian jar, because that jar file only makes sense in combination with the com.itextpdf.io main jar. Thus it's save to assume com.itextpdf.io.font.Type1Font is there, if we have font-asian jar on the classpath.

[olpaw]

Thus it's save to assume com.itextpdf.io.font.Type1Font is there, if we have font-asian jar on the classpath.

But it would be even better if you know of a class that only gets reachable if one of the resources from font-asian.jar are used. This way an image using com.itextpdf.io would be smaller if none of the resources from font-asian.jar are used by the application that uses com.itextpdf.io.

[vitali-pr]

Thus it's save to assume com.itextpdf.io.font.Type1Font is there

@olpaw , You are right, it will be com.itextpdf.io.font.CidFont then. But the problem is that we don't test these resources using CidFont class. So without a fake CidFont usage in the tests, the tests will just fail in native. Also who knows how users are supposed to use these resources, maybe they'd implement their own FontProgram.
Anyway, I think I found a compromise by just adding com.itextpdf.io.font.CjkResourceLoader type as a condition. I've added a new commit to the review.

But it would be even better if you know of a class that only gets reachable if one of the resources from font-asian.jar are used.

There are no such per cmap classes.

[olpaw]

@vitali-pr your PR is now on master. Thank you for your contribution!