uschindler edited a comment on pull request #567: URL: https://github.com/apache/lucene/pull/567#issuecomment-1000312397
> > I am thinking about a small solution to still use `StopAnalyzerBase#loadStopwordSet(...,Class,...)` and not duplicate code everywhere like in current patch. > > But how will we fix analyzer factories (ClasspathResourceLoader) ? This seems like the biggest issue. The class will work well in ClassPath mode, of course (the name is alread "Classpath*"). But we should deprecate the constructor that takes a class and/or add a ModuleResourceLoader taking a set of java modules. But that's a separate issue. The ctor taking a ClassLoader can be initialized by an app like a modularized Elasticsearch or Solr using a ClassLoader retrieved from the module. We did this inside Luke already. But still the package needs to open all its resource folders. This will be a pain. Nevertheless for Lucene itsself it is not a problem, because we know our module graph. It is just bad that we can't provide those simple "utility" methods to the outside. I also checked the Module system classlaoders and the Module class, all are caller sensitive. IMHO, it's a pain that so much reflection specific stuff is now caller sensitive (since Java 9), this makes utility methods impossible to expose. It is not only getResource, also a lot of other shit like classloader access and also Class.forName() is now caller sensitive! -- 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
