You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Stefan Bodewig <bo...@apache.org> on 2011/01/27 10:36:55 UTC
IKVM (or rather OpenJDK) License Problem
Hi,
sorry I started this before doing my homework. If we took the IKVM
route Lucene.NET's binary distribution could not bundle the OpenJDK
derived DLLs. They are licensed as GPL2 + Classpath Exception[1] which
is part of the list of explicitly prohibited licenses for ASF
distributions[2].
This would mean users had to download the DLL from the IKVM site
themselves which sounds pretty inconvient.
Stefan
[1] http://sourceforge.net/apps/mediawiki/ikvm/index.php?title=License
[2] http://www.apache.org/legal/resolved.html#category-x
Re: IKVM (or rather OpenJDK) License Problem
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-01-28, digy digy wrote:
>>> * 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.
Understood, thanks
Stefan
Re: IKVM (or rather OpenJDK) License Problem
Posted by digy digy <di...@gmail.com>.
>> * 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 <bo...@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
>
Re: IKVM (or rather OpenJDK) License Problem
Posted by Stefan Bodewig <bo...@apache.org>.
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
Re: IKVM (or rather OpenJDK) License Problem
Posted by digy digy <di...@gmail.com>.
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 <bo...@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
>
Re: IKVM (or rather OpenJDK) License Problem
Posted by Stefan Bodewig <bo...@apache.org>.
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
RE: IKVM (or rather OpenJDK) License Problem
Posted by "Granroth, Neal V." <ne...@thermofisher.com>.
Use of IKVM was discussed before.
Adding this layer (or any other shim) on top of Lucene.NET is extremely unpalatable in the environment in which our products are deployed.
For these products, I would have to abandon use of Lucene.NET.
- Neal
-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org]
Sent: Thursday, January 27, 2011 3:37 AM
To: lucene-net-dev@lucene.apache.org
Subject: IKVM (or rather OpenJDK) License Problem
Hi,
sorry I started this before doing my homework. If we took the IKVM
route Lucene.NET's binary distribution could not bundle the OpenJDK
derived DLLs. They are licensed as GPL2 + Classpath Exception[1] which
is part of the list of explicitly prohibited licenses for ASF
distributions[2].
This would mean users had to download the DLL from the IKVM site
themselves which sounds pretty inconvient.
Stefan
[1] http://sourceforge.net/apps/mediawiki/ikvm/index.php?title=License
[2] http://www.apache.org/legal/resolved.html#category-x
Re: IKVM (or rather OpenJDK) License Problem
Posted by Ayende Rahien <ay...@ayende.com>.
It would also have drastic affects on other people using Lucene for
commercial and OSS projects.
On Thu, Jan 27, 2011 at 11:36 AM, Stefan Bodewig <bo...@apache.org> wrote:
> Hi,
>
> sorry I started this before doing my homework. If we took the IKVM
> route Lucene.NET's binary distribution could not bundle the OpenJDK
> derived DLLs. They are licensed as GPL2 + Classpath Exception[1] which
> is part of the list of explicitly prohibited licenses for ASF
> distributions[2].
>
> This would mean users had to download the DLL from the IKVM site
> themselves which sounds pretty inconvient.
>
> Stefan
>
> [1] http://sourceforge.net/apps/mediawiki/ikvm/index.php?title=License
>
> [2] http://www.apache.org/legal/resolved.html#category-x
>