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

Reply via email to