uschindler commented on pull request #567: URL: https://github.com/apache/lucene/pull/567#issuecomment-1003236100
> The same could be achieved by adding "opens a" or just declaring the module as open. While this does somewhat-work, I think changing the Lucene API is a better solution because it doesn't require people to open up entire packages (to reflection and resource-access) just so that IOUtil can open a single file. Yes, opens can be qualified at module-descriptor level but it introduces a level of sophistication I find hardly justifiable. Yes this PR fixes it. There is one place where applications may need resources: when they use analyzer builders, and there they can now use ModuleResourceLoader instead of ClasspathResourceLoader. But they have to declare in their module descriptor that the packages containing resources are open `TO org.apache.lucene.core`. There are some remaining issues with code doing: Class.getClassLoader().getResource.... This code does not even work from inside the same module and always returns null. In most cases this is just a bug: From what I see it only affects BinaryDictionary in Kuromoji and Nori. As said before this should be refactored to not have this crazy File vs. Resource options from former times not applicable to Lucene anymore. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
