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
