Hi Stefan, * Java's bytecode doesn't contain metadata about generics and when Java is compiled, all info about generics gets lost. So, IKVMed Lucene.Net will have to live without generics.
* IKVM is the java world in .NET runtime in fact. If you are , for ex, to write an analyzer, you have to override TokenStream method which accepts "java.io.Reader" instead of "System.IO.TextReader". So .NET people have to learn java namespaces/classes and develop their own java-compatible libraries * Since IKVM is a different world, remoting (for ex.) between native .NET code & IKVMed code is problematic (one uses "java.rmi.server.UnicastRemoteObject", the other one "System.MarshalByRefObject"). * It's not possible to make custom changes in IKVMed Lucene.NET unless you make your changes in java sources and compile them. I think people can find more examples. Of course, none of them is a blocking issue but too far from giving a .NET taste. DIGY On Fri, Jan 28, 2011 at 7:24 AM, Stefan Bodewig <bode...@apache.org> wrote: > On 2011-01-27, Granroth, Neal V. wrote: > > > Use of IKVM was discussed before. > > I'm really sorry. Normally I wouldn't have brought it up without > searching the archive - I did so in the context of "this is a question > the people we hope to attract might ask". > > Please be patient with the new people we want to attract, they will not > hunt down the mailing list archives for every idea they have. This is > why putting things on the Wiki like Scott has started is a better > approach. You can tell people "was discussed before and URL-HERE is the > outcome". > > > Adding this layer (or any other shim) on top of Lucene.NET is > > extremely unpalatable in the environment in which our products are > > deployed. > > The license rules it out anyway (unless we ikvmc'ed Harmony, yet another > can of worms) so this question is moot. But still, out of curiosity: is > there any technical reason that turned it into a bad idea? The > discussion from the other thread seemed to indicate that performance was > not an issue. > > Thanks > > Stefan >
