Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/209
> Actually way back the first time I began to look into Lucene on .NET I
did come across a few other attempts on just that, but I guess they died off in
favor for this, and to some extend thanks for that because one of them
attempted to use a RAW port (no .NET-fications) and then just build a wrapper
around it, in theory a good idea if you could do fully automated porting for
every Lucene release, but in practice not viable at all I think...
> Other solutions simply used a JNBridge and the Lucene Jar's... No idea
how well that would work, again I think you would have the wrapper layer.
Sounds awfully ineffective...
It sounds like you are referring to what happens when you use
[IKVM](http://www.ikvm.net/userguide/tutorial.html) to convert a `.jar` to MSIL
byte code. You get a full-on Java-style API including the ridiculously long
namespace names.
I recently have been looking into using it to avoid porting some of the
Analysis dependencies (such as UIMA, which is quite large). I wouldn't use
such a thing for Lucene.Net because of the performance impact it would have
(which I have read is something like a 20-25% loss, but I suspect would be much
higher than that). But even [Standford
University](https://sergey-tihon.github.io/Stanford.NLP.NET/) is using
IKVM-processed Java for natural language processing, so I think this would be
adequate for (at least index time) analysis.
Unfortunately, even that (apparently long-standing) project has [recently
died out](http://weblog.ikvm.net/default.aspx). There will never be .NET
Standard support for IKVM unless someone picks up the torch and keeps moving it
forward.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
