uschindler commented on pull request #567: URL: https://github.com/apache/lucene/pull/567#issuecomment-1003328772
> Yeah - we came up with the same explanation independently, Uwe. In my opinion a simpler API that does not require special module-info clauses is a preference (if it can be done in a different way, avoiding that opens clause) - it took us a moment to realize why it doesn't work and it'll be a constant source of frustration to developers (and nobody reads the docs...). That was funny, indeed. I did not see your message, so sorry for pinging you in chat at midnight :-) Actually, except the dictionary stuff, all is solved here by deprecating the helper APIs and adding more convenience methods to WordListLoader taking InputStreams (with charset or default to UTF-8). I also added a test that shows that resource loading won't work with non-open packages (exporting is not enough, it must be OPEN). Stupidly when reading the JDK code the naiming there is horrible: all the terms "exported", "open", "readable" are so close together and you simply get irritated, especially as the code is no deep. The main problem with JDK's naiming is that they never use "exported" in the API, only "module can read" and also "open" at other places. This is all a desaster as it makes it too hard to understand what's going on. This PR also add for the CustomAnalyzers used in Solr/ES/Luke the ResourceLoadervinterface specialized for the Module system (see above). If you could have a look at that, please review! -- 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
