[
https://issues.apache.org/jira/browse/LUCENE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061488#comment-17061488
]
Dawid Weiss commented on LUCENE-9281:
-------------------------------------
I see two possibilities:
1) A cleaner and more reasonable fix would be to have no-arg public
constructors on SPI classes and a single-call initialize(Map<>) method (any
subsequent call throwing an exception). Sure, it would make things a bit uglier
(no final fields for variables extracted from the map). Maybe some it could be
engineered to be a bit nicer: those factory classes could have a final field of
the kind of {{OneTimeSupplier<ClassOptions> options = new
OneTimeSupplier((argsMap) -> new ClassOptions<>(argsMap))}} and this could
ensure the options are initialized once, with get() still being fairly fast.
2) A hacky way is to create a thread-local {{Map<> OptionsSupplier.get()}}
which would be set up temporarily for the thread enumerating the SPI. Then the
public constructor in factory classes can extract argsMap from this thread
local:
{{Foo() { this(}}{{OptionsSupplier.get());}}}
{{Neither is particularly pretty.}}
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
