You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Uwe Schindler (Jira)" <ji...@apache.org> on 2020/03/17 23:13:00 UTC

[jira] [Commented] (LUCENE-9281) Retire SPIClassIterator from master because Java 9+ uses different mechanism to load services when module system is used

    [ https://issues.apache.org/jira/browse/LUCENE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061246#comment-17061246 ] 

Uwe Schindler commented on LUCENE-9281:
---------------------------------------

I did a quick mockup, but unfortunately with the stream() it still checks the constructor:
- Core worked perfectly, all custom code can be nuked. Reload, everything works out of box with NamedSPILoader.
- Analysis broke, although it says "lazy" in documentation ("Returns the provider type. There is no guarantee that this type is accessible or that it has a public no-args constructor."). It fails because there is no no-arg public ctor in factory classes.

Not sure how to fix this, IMHO we should at least remove SPIClassIterator from core (Codecs) and think about how to improve analysis factories so we can work around this issue. We may add a fake ctor, but that sounds bad.

> Retire SPIClassIterator from master because Java 9+ uses different mechanism to load services when module system is used
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-9281
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9281
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/other
>    Affects Versions: master (9.0)
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>            Priority: Major
>             Fix For: master (9.0)
>
>
> We currently have our own implementation of the service loader standard (SPI) fo several reasons:
> (1) In some older JDKs the order of classpath was not respected and this lead to wrong order of codecs implementing the same SPI name. This caused tests to sometimes use wrong class (we had this in Lucene 4 where we had a test-only read/write Lucene3 codec that was listed before the read-only one). That's no longer an issue, the order of loading does not matter. In addition, Java now does everything correct.
> (2) In Analysis, we require SPI classes to have a constructor taking args (a Map of params in our case). We also extract the NAME from a static field. Standard service loader does not support this, it tries to instantiate the class with default ctor.
> With Java 9+, the ServiceLoader now has a stream() method that allows to filter and preprocess classes: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.html#stream()
> This allows us to use the new interface and just get the loaded class (which may come from module-info.class or a conventional SPI file): https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.Provider.html#type()
> This change allows us to convert Lucene to modules listing all SPIs in the module-info.java.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org