If .NET and Java framework were static, I would agree with you but, there
are always additions and modifications.
So, I think it is very hard for a project to keep track of the changes in
both environment and make the necessary
modifications in libraries.
-------------------------------------------------
... ... ...
Yes, I think to myself, what a wonderful world
Louis Armstrong
-------------------------------------------------
DIGY
-----Original Message-----
From: Smiley, David W. (DSMILEY) [mailto:[EMAIL PROTECTED]
Sent: Monday, March 03, 2008 10:35 PM
To: [email protected]
Subject: Re: Why translated to C#? Doesn't the CLR avoid the need for ports?
Importance: Low
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
>
