I see what you're saying. It'd be nice if iKVM had mechanisms to automatically wrap classes that are equivalent in both languages (like java.io.Reader and System.IO.TextReader ). It wouldn't be perfect but it might be something that would be good enough so that library-porting to the CLR would be a less frequent occurrence. Ah well. Perhaps the iKVM developers could use this feedback.
~ David On 3/3/08 3:21 PM, "Digy" <[EMAIL PROTECTED]> wrote: > > Hi David, > > Starting with IKVM; it is a very great tool. It can be used in many cases > where .NET version is not available. > But; > > * Remoting objects is somehow problematic unless both server(where > lucene.java resides) and client are written > in Java and then converted to .NET (or unless they are written by using Java > Libraries on IKVM framework). > [for ex, > IKVM converts RemoteSearchable class as > public class RemoteSearchable : UnicastRemoteObject, > Searchable, Remote > where is should be > public class RemoteSearchable : System.MarshalByRefObject, > Searchable > ] > > > * IKVM forces to use the classes directly converted from java. > [for ex, java.io.Reader instead of System.IO.TextReader in Analyzer] > This limits the flexibility of the .NET programmer with the IKVM runtime > environment. (or he must develop > new libraries compatible with java). > > > Many more examples can be found where .NET programmer must first think its > java counterpart and then develop the > .NET version which , I think, is not acceptable as a pure .NET developer. > The same problems also exist with J# too. > > > > I think, this can be tought as developing user interfaces with Tcl/Tk.NET > libraries. They are good but not accepted as a > general GUI-framework in .NET world. Additionally, .NET programmer doesn't > have to know the java namespaces/classes > (provided by IKVM runtime or by others) to develop .NET code. > > > Lastly, I make changes in the Lucene.Net codes for some specific cases while > developing my projects. If I would use a tool like > that then I would have to make these changes first in java version (where my > only trial is a "Hello World" application). > > So, I can try to interpret(understand) the Java code while porting the > Lucene, but I am not willing to use the java convention in > developing pure .NET codes. > > DIGY > > > > > > > > -----Original Message----- > From: David Smiley [mailto:[EMAIL PROTECTED] > Sent: Monday, March 03, 2008 7:32 AM > To: [email protected] > Subject: Why translated to C#? Doesn't the CLR avoid the need for ports? > > Hi; I stumbled across Lucene.Net. I'm a Java developer, not a C#/.Net dev. > I thought there is an option or two for Java programs to run on Microsoft's > cool Common-Language-Runtime. If so, it seems to me quite odd that > Lucene.Net would need to be ported to another programming language. Part of > the beauty of the CLR is that you don't need to do these sorts of things. > Because it's a common runtime and different languages can interoperate > (within reason). Even though whatever Java implementation for the CLR isn't > a perfect replica of Sun's implementation and would necessitate some changes > to Lucene, it's hard for me to believe that doing a language port would make > more sense than working on those tweaks. Please fill me in on the > rationale. You might want to put the response in a FAQ somewhere. The > website doesn't have one. > > Thanks. > > ~ David Smiley >
