>> * It's not possible to make custom changes in IKVMed Lucene.NET unless you >> make your changes in java sources and compile them.
> Wouldn't a "custom change" contradict the goal of a line-by-line > translation? What I intented to say was customizations made by Lucene.Net users, not as a Lucene.Net project. DIGY On Fri, Jan 28, 2011 at 10:44 AM, Stefan Bodewig <bode...@apache.org> wrote: > Hi DIGY > > On 2011-01-28, digy digy wrote: > > > * 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. > > Ah, yes, the joys of type erasure. I completely missed that. > > > * 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"). > > Ugly, I agree. Although this could be meliorated by an additional .NET > centric library that took care of adapting the differences. This extra > layer would add complexity and not help with performance, of course. > > > * It's not possible to make custom changes in IKVMed Lucene.NET unless > you > > make your changes in java sources and compile them. > > Wouldn't a "custom change" contradict the goal of a line-by-line > translation? > > Many thanks, I'll add your points to the wiki > > Stefan >
