You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by DM Smith <dm...@woh.rr.com> on 2010/12/05 00:16:08 UTC
Exception in migrating from 2.9.x to 3.0.2 on Android
The current code that works on Android with 2.9.1, but fails with 3.0.2:
Directory dir = FSDirectory.open(file);
...
do something with directory
...
The error we're seeing is:
12-04 21:34:41.629: WARN/System.err(23160): java.lang.NoClassDefFoundError: java.lang.management.ManagementFactory
12-04 21:34:41.639: WARN/System.err(23160): at org.apache.lucene.store.NativeFSLockFactory.acquireTestLock(NativeFSLockFactory.java:87)
12-04 21:34:41.639: WARN/System.err(23160): at org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactory.java:142)
12-04 21:34:41.649: WARN/System.err(23160): at org.apache.lucene.store.Directory.makeLock(Directory.java:106)
12-04 21:34:41.649: WARN/System.err(23160): at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1058)
Turns out Android does not have java.lang.management.ManagementFactory.
There are several work arounds in client code, but not sure what is best.
The bigger question is whether and how Lucene should be modified to accommodate?
Ultimately FSDirectory.open does the following:
if (Constants.WINDOWS) {
return new SimpleFSDirectory(path, lockFactory);
} else {
return new NIOFSDirectory(path, lockFactory);
}
Should Android be a supported client OS?
If so, wouldn't it be better not to have OS specific if-then-else and use reflection or something else?
Thanks,
DM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Gérard Dupont <ge...@gmail.com>.
On 5 December 2010 00:16, DM Smith <dm...@woh.rr.com> wrote:
> Should Android be a supported client OS?
> If so, wouldn't it be better not to have OS specific if-then-else and use
> reflection or something else?
>
Well Lucene is only relying on standard JVM API. The fact that Androïd is
using a non-standard JVM is IMHO outside the the scope of Lucene.
--
Gérard Dupont
Information Processing Control and Cognition (IPCC)
CASSIDIAN - an EADS company
Document & Learning team - LITIS Laboratory
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Mark Miller <ma...@gmail.com>.
bq. Perhaps that is not possible or too difficult in every case
To clarify - sounds like I could be saying, well, perhaps we can't
improve every case, but some we can. I'm saying *too difficult in every*
case - even if we don't try and *fix a single case* - its still
beneficial for you to report and discuss these issues IMO. And as I
said, I'll remain interested.
- Mark
On 12/5/10 3:40 PM, Mark Miller wrote:
> I have an interest - don't really care if it uses true java or not. I
> say keep it coming. Where/if it makes sense, why not make lucene work
> better with it. Perhaps that is not possible or too difficult in every
> case - but I'd still like to see the cases pop up. Better than those
> spam wiki update emails.
>
> - Mark
>
> On 12/5/10 3:36 PM, DM Smith wrote:
>> Thanks Uwe (and others). We'll adapt.
>>
>> Is there any interest here in knowing if there are any other problems
>> regarding Lucene on Android? From what I see, it is the first mobile
>> platform on which Lucene can run.
>>
>> -- DM
>>
>> On Dec 5, 2010, at 5:16 AM, Uwe Schindler wrote:
>>
>>> Hi DM,
>>>
>>> In Lucene 3.0.3, NativeFSLockFactory no longer aquires a test log and
>>> does
>>> not need the process ID anymore, so java.lang.management package is no
>>> longer used.
>>>
>>> In general, Lucene Java is compatible to the Java 5 SE specification.
>>> Android uses Harmony and therefore we cannot guarantee compatibility as
>>> Harmony is not TCK tested (but we do with latest versions, soon there
>>> will
>>> also be tests on Hudson with Harmony). But only latest versions of
>>> Harmony
>>> are really compatible with Lucene, previous versions fail lots of
>>> tests (ask
>>> Robert), and Android phones use very antique versions of Harmony - it
>>> is not
>>> even sure, that the Java5 Memory Model is correctly implemented in
>>> Dalvik!
>>>
>>> About 3.0.2: Of course this version even works with latest Harmony, so
>>> Harmony has java.lang.management package (which is java.lang!!!), so
>>> the bug
>>> is in Android, simply by excluding a SE package. So you should open bug
>>> report at Google and then hope that they fix it and all the phone
>>> manufacturers like Motor-Roller will update their Android versions.
>>>
>>> For your problem: The easy workaround is using Lucene 3.0.3 or simply
>>> use
>>> another LockFactory (Andoid is single user so even NoLockFactory
>>> would be
>>> fine in most cases). This are the same limitations like with the NFS
>>> filesystem. Just use FSDir.open(dir, lockFactory).
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de
>>>
>>>> -----Original Message-----
>>>> From: DM Smith [mailto:dm-smith@woh.rr.com]
>>>> Sent: Sunday, December 05, 2010 12:16 AM
>>>> To: dev@lucene.apache.org
>>>> Subject: Exception in migrating from 2.9.x to 3.0.2 on Android
>>>>
>>>> The current code that works on Android with 2.9.1, but fails with
>>>> 3.0.2:
>>>>
>>>> Directory dir = FSDirectory.open(file);
>>>> ...
>>>> do something with directory
>>>> ...
>>>>
>>>> The error we're seeing is:
>>>> 12-04 21:34:41.629: WARN/System.err(23160):
>>>> java.lang.NoClassDefFoundError:
>>>> java.lang.management.ManagementFactory
>>>> 12-04 21:34:41.639: WARN/System.err(23160): at
>>>> org.apache.lucene.store.NativeFSLockFactory.acquireTestLock(NativeFSLock
>>>>
>>>> Factory.java:87)
>>>> 12-04 21:34:41.639: WARN/System.err(23160): at
>>>> org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactor
>>>> y.java:142)
>>>> 12-04 21:34:41.649: WARN/System.err(23160): at
>>>> org.apache.lucene.store.Directory.makeLock(Directory.java:106)
>>>> 12-04 21:34:41.649: WARN/System.err(23160): at
>>>> org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1058)
>>>>
>>>> Turns out Android does not have
>>>> java.lang.management.ManagementFactory.
>>>>
>>>> There are several work arounds in client code, but not sure what is
>>>> best.
>>>>
>>>> The bigger question is whether and how Lucene should be modified to
>>>> accommodate?
>>>>
>>>> Ultimately FSDirectory.open does the following:
>>>> if (Constants.WINDOWS) {
>>>> return new SimpleFSDirectory(path, lockFactory);
>>>> } else {
>>>> return new NIOFSDirectory(path, lockFactory);
>>>> }
>>>>
>>>> Should Android be a supported client OS?
>>>>
>>>> If so, wouldn't it be better not to have OS specific if-then-else
>>>> and use
>>>> reflection or something else?
>>>>
>>>> Thanks,
>>>> DM
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>>>> additional
>>>> commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Robert Muir <rc...@gmail.com>.
On Sun, Dec 5, 2010 at 9:12 PM, Simon Willnauer
<si...@googlemail.com> wrote:
> I personally consider android a valid platform for lucene and we
> should try to reduce the pain for android folks as much as possible.
> Changing supported platforms is a totally different thing to me.
>
good, you can start a separate subproject as a port then.
but until then, android isnt supported by lucene-java.
android is a different programming language, and by supporting it, we
change the programming language of the lucene-java project.
this requires a vote, until then, its not supported by definition
since our documented programming language is java, not android.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Simon Willnauer <si...@googlemail.com>.
Mark, Robert can we keep things constructive here please. The issue
what DM is reporting might not be valid on "true" java and nobody asks
for specializing code for the android platform. I figure from uwes
response that this issue can be solved easily so not a real big deal.
If not we should try to take issues like that serious and find a good
solution without starting a flame war.
I personally consider android a valid platform for lucene and we
should try to reduce the pain for android folks as much as possible.
Changing supported platforms is a totally different thing to me.
simon
On Mon, Dec 6, 2010 at 12:21 AM, Mark Miller <ma...@gmail.com> wrote:
> On 12/5/10 6:15 PM, Robert Muir wrote:
>>
>> On Sun, Dec 5, 2010 at 6:10 PM, Mark Miller<ma...@gmail.com> wrote:
>>>
>>> On 12/5/10 5:05 PM, Robert Muir wrote:
>>>>
>>>> what I am saying, is that this is a java project, and I don't want to
>>>> write to some least common denominator/intersection of java and android.
>>>
>>> So don't - DM submitting cases that don't work and you not giving a shit
>>> are
>>> not mutually exclusive.
>>>
>>
>> Just trying to say, i dont think we should change the programming
>> language of the project without a proper vote.
>>
>
> Then your just overreacting again.
>
> Allow me to sum up for you:
>
> DM: hey, we are trying to use lucene on android - this is not working
> Uwe and someone: thats not real java, we don't support it
> Rmuir : **%$&$!! (kidding - i dont remember what you said)
> DM: Oh, pardon me. Well okay - but would anyone be interested in us
> reporting what doesn't work as we go through this? Android is the only
> mobile platform lucene works on I think.
> Mark: Oh yeah - interesting - please do. I'd be interested in seeing.
> Rmuir: don't change the lucene impl language without a vote! Grrrrr!
> Mark: ??????????????????
> Native Police: why are you so aggressive?
>
>
> - Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Mark Miller <ma...@gmail.com>.
On 12/5/10 6:15 PM, Robert Muir wrote:
> On Sun, Dec 5, 2010 at 6:10 PM, Mark Miller<ma...@gmail.com> wrote:
>> On 12/5/10 5:05 PM, Robert Muir wrote:
>>>
>>> what I am saying, is that this is a java project, and I don't want to
>>> write to some least common denominator/intersection of java and android.
>>
>> So don't - DM submitting cases that don't work and you not giving a shit are
>> not mutually exclusive.
>>
>
> Just trying to say, i dont think we should change the programming
> language of the project without a proper vote.
>
Then your just overreacting again.
Allow me to sum up for you:
DM: hey, we are trying to use lucene on android - this is not working
Uwe and someone: thats not real java, we don't support it
Rmuir : **%$&$!! (kidding - i dont remember what you said)
DM: Oh, pardon me. Well okay - but would anyone be interested in us
reporting what doesn't work as we go through this? Android is the only
mobile platform lucene works on I think.
Mark: Oh yeah - interesting - please do. I'd be interested in seeing.
Rmuir: don't change the lucene impl language without a vote! Grrrrr!
Mark: ??????????????????
Native Police: why are you so aggressive?
- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Robert Muir <rc...@gmail.com>.
On Sun, Dec 5, 2010 at 6:10 PM, Mark Miller <ma...@gmail.com> wrote:
> On 12/5/10 5:05 PM, Robert Muir wrote:
>>
>> what I am saying, is that this is a java project, and I don't want to
>> write to some least common denominator/intersection of java and android.
>
> So don't - DM submitting cases that don't work and you not giving a shit are
> not mutually exclusive.
>
Just trying to say, i dont think we should change the programming
language of the project without a proper vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Mark Miller <ma...@gmail.com>.
On 12/5/10 5:05 PM, Robert Muir wrote:
> what I am saying, is that this is a java project, and I don't want to
> write to some least common denominator/intersection of java and android.
So don't - DM submitting cases that don't work and you not giving a shit
are not mutually exclusive.
- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Robert Muir <rc...@gmail.com>.
what I am saying, is that this is a java project, and I don't want to write
to some least common denominator/intersection of java and android. if an api
doesn't exist in android, I could care less. inzstead, why can't interest
parties have a little project where we port lucene java (perhaps a trivial
patch), setup automated/tests etc. this I would be interested in, but let's
keep lucene java as java
On Dec 5, 2010 9:40 PM, "Mark Miller" <ma...@gmail.com> wrote:
> I have an interest - don't really care if it uses true java or not. I
> say keep it coming. Where/if it makes sense, why not make lucene work
> better with it. Perhaps that is not possible or too difficult in every
> case - but I'd still like to see the cases pop up. Better than those
> spam wiki update emails.
>
> - Mark
>
> On 12/5/10 3:36 PM, DM Smith wrote:
>> Thanks Uwe (and others). We'll adapt.
>>
>> Is there any interest here in knowing if there are any other problems
regarding Lucene on Android? From what I see, it is the first mobile
platform on which Lucene can run.
>>
>> -- DM
>>
>> On Dec 5, 2010, at 5:16 AM, Uwe Schindler wrote:
>>
>>> Hi DM,
>>>
>>> In Lucene 3.0.3, NativeFSLockFactory no longer aquires a test log and
does
>>> not need the process ID anymore, so java.lang.management package is no
>>> longer used.
>>>
>>> In general, Lucene Java is compatible to the Java 5 SE specification.
>>> Android uses Harmony and therefore we cannot guarantee compatibility as
>>> Harmony is not TCK tested (but we do with latest versions, soon there
will
>>> also be tests on Hudson with Harmony). But only latest versions of
Harmony
>>> are really compatible with Lucene, previous versions fail lots of tests
(ask
>>> Robert), and Android phones use very antique versions of Harmony - it is
not
>>> even sure, that the Java5 Memory Model is correctly implemented in
Dalvik!
>>>
>>> About 3.0.2: Of course this version even works with latest Harmony, so
>>> Harmony has java.lang.management package (which is java.lang!!!), so the
bug
>>> is in Android, simply by excluding a SE package. So you should open bug
>>> report at Google and then hope that they fix it and all the phone
>>> manufacturers like Motor-Roller will update their Android versions.
>>>
>>> For your problem: The easy workaround is using Lucene 3.0.3 or simply
use
>>> another LockFactory (Andoid is single user so even NoLockFactory would
be
>>> fine in most cases). This are the same limitations like with the NFS
>>> filesystem. Just use FSDir.open(dir, lockFactory).
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de
>>>
>>>> -----Original Message-----
>>>> From: DM Smith [mailto:dm-smith@woh.rr.com]
>>>> Sent: Sunday, December 05, 2010 12:16 AM
>>>> To: dev@lucene.apache.org
>>>> Subject: Exception in migrating from 2.9.x to 3.0.2 on Android
>>>>
>>>> The current code that works on Android with 2.9.1, but fails with
3.0.2:
>>>>
>>>> Directory dir = FSDirectory.open(file);
>>>> ...
>>>> do something with directory
>>>> ...
>>>>
>>>> The error we're seeing is:
>>>> 12-04 21:34:41.629: WARN/System.err(23160):
>>>> java.lang.NoClassDefFoundError:
>>>> java.lang.management.ManagementFactory
>>>> 12-04 21:34:41.639: WARN/System.err(23160): at
>>>>
org.apache.lucene.store.NativeFSLockFactory.acquireTestLock(NativeFSLock
>>>> Factory.java:87)
>>>> 12-04 21:34:41.639: WARN/System.err(23160): at
>>>> org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactor
>>>> y.java:142)
>>>> 12-04 21:34:41.649: WARN/System.err(23160): at
>>>> org.apache.lucene.store.Directory.makeLock(Directory.java:106)
>>>> 12-04 21:34:41.649: WARN/System.err(23160): at
>>>> org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1058)
>>>>
>>>> Turns out Android does not have
>>>> java.lang.management.ManagementFactory.
>>>>
>>>> There are several work arounds in client code, but not sure what is
best.
>>>>
>>>> The bigger question is whether and how Lucene should be modified to
>>>> accommodate?
>>>>
>>>> Ultimately FSDirectory.open does the following:
>>>> if (Constants.WINDOWS) {
>>>> return new SimpleFSDirectory(path, lockFactory);
>>>> } else {
>>>> return new NIOFSDirectory(path, lockFactory);
>>>> }
>>>>
>>>> Should Android be a supported client OS?
>>>>
>>>> If so, wouldn't it be better not to have OS specific if-then-else and
use
>>>> reflection or something else?
>>>>
>>>> Thanks,
>>>> DM
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
additional
>>>> commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Mark Miller <ma...@gmail.com>.
I have an interest - don't really care if it uses true java or not. I
say keep it coming. Where/if it makes sense, why not make lucene work
better with it. Perhaps that is not possible or too difficult in every
case - but I'd still like to see the cases pop up. Better than those
spam wiki update emails.
- Mark
On 12/5/10 3:36 PM, DM Smith wrote:
> Thanks Uwe (and others). We'll adapt.
>
> Is there any interest here in knowing if there are any other problems regarding Lucene on Android? From what I see, it is the first mobile platform on which Lucene can run.
>
> -- DM
>
> On Dec 5, 2010, at 5:16 AM, Uwe Schindler wrote:
>
>> Hi DM,
>>
>> In Lucene 3.0.3, NativeFSLockFactory no longer aquires a test log and does
>> not need the process ID anymore, so java.lang.management package is no
>> longer used.
>>
>> In general, Lucene Java is compatible to the Java 5 SE specification.
>> Android uses Harmony and therefore we cannot guarantee compatibility as
>> Harmony is not TCK tested (but we do with latest versions, soon there will
>> also be tests on Hudson with Harmony). But only latest versions of Harmony
>> are really compatible with Lucene, previous versions fail lots of tests (ask
>> Robert), and Android phones use very antique versions of Harmony - it is not
>> even sure, that the Java5 Memory Model is correctly implemented in Dalvik!
>>
>> About 3.0.2: Of course this version even works with latest Harmony, so
>> Harmony has java.lang.management package (which is java.lang!!!), so the bug
>> is in Android, simply by excluding a SE package. So you should open bug
>> report at Google and then hope that they fix it and all the phone
>> manufacturers like Motor-Roller will update their Android versions.
>>
>> For your problem: The easy workaround is using Lucene 3.0.3 or simply use
>> another LockFactory (Andoid is single user so even NoLockFactory would be
>> fine in most cases). This are the same limitations like with the NFS
>> filesystem. Just use FSDir.open(dir, lockFactory).
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>> -----Original Message-----
>>> From: DM Smith [mailto:dm-smith@woh.rr.com]
>>> Sent: Sunday, December 05, 2010 12:16 AM
>>> To: dev@lucene.apache.org
>>> Subject: Exception in migrating from 2.9.x to 3.0.2 on Android
>>>
>>> The current code that works on Android with 2.9.1, but fails with 3.0.2:
>>>
>>> Directory dir = FSDirectory.open(file);
>>> ...
>>> do something with directory
>>> ...
>>>
>>> The error we're seeing is:
>>> 12-04 21:34:41.629: WARN/System.err(23160):
>>> java.lang.NoClassDefFoundError:
>>> java.lang.management.ManagementFactory
>>> 12-04 21:34:41.639: WARN/System.err(23160): at
>>> org.apache.lucene.store.NativeFSLockFactory.acquireTestLock(NativeFSLock
>>> Factory.java:87)
>>> 12-04 21:34:41.639: WARN/System.err(23160): at
>>> org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactor
>>> y.java:142)
>>> 12-04 21:34:41.649: WARN/System.err(23160): at
>>> org.apache.lucene.store.Directory.makeLock(Directory.java:106)
>>> 12-04 21:34:41.649: WARN/System.err(23160): at
>>> org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1058)
>>>
>>> Turns out Android does not have
>>> java.lang.management.ManagementFactory.
>>>
>>> There are several work arounds in client code, but not sure what is best.
>>>
>>> The bigger question is whether and how Lucene should be modified to
>>> accommodate?
>>>
>>> Ultimately FSDirectory.open does the following:
>>> if (Constants.WINDOWS) {
>>> return new SimpleFSDirectory(path, lockFactory);
>>> } else {
>>> return new NIOFSDirectory(path, lockFactory);
>>> }
>>>
>>> Should Android be a supported client OS?
>>>
>>> If so, wouldn't it be better not to have OS specific if-then-else and use
>>> reflection or something else?
>>>
>>> Thanks,
>>> DM
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>>> commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by DM Smith <dm...@gmail.com>.
Thanks Uwe (and others). We'll adapt.
Is there any interest here in knowing if there are any other problems regarding Lucene on Android? From what I see, it is the first mobile platform on which Lucene can run.
-- DM
On Dec 5, 2010, at 5:16 AM, Uwe Schindler wrote:
> Hi DM,
>
> In Lucene 3.0.3, NativeFSLockFactory no longer aquires a test log and does
> not need the process ID anymore, so java.lang.management package is no
> longer used.
>
> In general, Lucene Java is compatible to the Java 5 SE specification.
> Android uses Harmony and therefore we cannot guarantee compatibility as
> Harmony is not TCK tested (but we do with latest versions, soon there will
> also be tests on Hudson with Harmony). But only latest versions of Harmony
> are really compatible with Lucene, previous versions fail lots of tests (ask
> Robert), and Android phones use very antique versions of Harmony - it is not
> even sure, that the Java5 Memory Model is correctly implemented in Dalvik!
>
> About 3.0.2: Of course this version even works with latest Harmony, so
> Harmony has java.lang.management package (which is java.lang!!!), so the bug
> is in Android, simply by excluding a SE package. So you should open bug
> report at Google and then hope that they fix it and all the phone
> manufacturers like Motor-Roller will update their Android versions.
>
> For your problem: The easy workaround is using Lucene 3.0.3 or simply use
> another LockFactory (Andoid is single user so even NoLockFactory would be
> fine in most cases). This are the same limitations like with the NFS
> filesystem. Just use FSDir.open(dir, lockFactory).
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: DM Smith [mailto:dm-smith@woh.rr.com]
>> Sent: Sunday, December 05, 2010 12:16 AM
>> To: dev@lucene.apache.org
>> Subject: Exception in migrating from 2.9.x to 3.0.2 on Android
>>
>> The current code that works on Android with 2.9.1, but fails with 3.0.2:
>>
>> Directory dir = FSDirectory.open(file);
>> ...
>> do something with directory
>> ...
>>
>> The error we're seeing is:
>> 12-04 21:34:41.629: WARN/System.err(23160):
>> java.lang.NoClassDefFoundError:
>> java.lang.management.ManagementFactory
>> 12-04 21:34:41.639: WARN/System.err(23160): at
>> org.apache.lucene.store.NativeFSLockFactory.acquireTestLock(NativeFSLock
>> Factory.java:87)
>> 12-04 21:34:41.639: WARN/System.err(23160): at
>> org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactor
>> y.java:142)
>> 12-04 21:34:41.649: WARN/System.err(23160): at
>> org.apache.lucene.store.Directory.makeLock(Directory.java:106)
>> 12-04 21:34:41.649: WARN/System.err(23160): at
>> org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1058)
>>
>> Turns out Android does not have
>> java.lang.management.ManagementFactory.
>>
>> There are several work arounds in client code, but not sure what is best.
>>
>> The bigger question is whether and how Lucene should be modified to
>> accommodate?
>>
>> Ultimately FSDirectory.open does the following:
>> if (Constants.WINDOWS) {
>> return new SimpleFSDirectory(path, lockFactory);
>> } else {
>> return new NIOFSDirectory(path, lockFactory);
>> }
>>
>> Should Android be a supported client OS?
>>
>> If so, wouldn't it be better not to have OS specific if-then-else and use
>> reflection or something else?
>>
>> Thanks,
>> DM
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi DM,
In Lucene 3.0.3, NativeFSLockFactory no longer aquires a test log and does
not need the process ID anymore, so java.lang.management package is no
longer used.
In general, Lucene Java is compatible to the Java 5 SE specification.
Android uses Harmony and therefore we cannot guarantee compatibility as
Harmony is not TCK tested (but we do with latest versions, soon there will
also be tests on Hudson with Harmony). But only latest versions of Harmony
are really compatible with Lucene, previous versions fail lots of tests (ask
Robert), and Android phones use very antique versions of Harmony - it is not
even sure, that the Java5 Memory Model is correctly implemented in Dalvik!
About 3.0.2: Of course this version even works with latest Harmony, so
Harmony has java.lang.management package (which is java.lang!!!), so the bug
is in Android, simply by excluding a SE package. So you should open bug
report at Google and then hope that they fix it and all the phone
manufacturers like Motor-Roller will update their Android versions.
For your problem: The easy workaround is using Lucene 3.0.3 or simply use
another LockFactory (Andoid is single user so even NoLockFactory would be
fine in most cases). This are the same limitations like with the NFS
filesystem. Just use FSDir.open(dir, lockFactory).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: DM Smith [mailto:dm-smith@woh.rr.com]
> Sent: Sunday, December 05, 2010 12:16 AM
> To: dev@lucene.apache.org
> Subject: Exception in migrating from 2.9.x to 3.0.2 on Android
>
> The current code that works on Android with 2.9.1, but fails with 3.0.2:
>
> Directory dir = FSDirectory.open(file);
> ...
> do something with directory
> ...
>
> The error we're seeing is:
> 12-04 21:34:41.629: WARN/System.err(23160):
> java.lang.NoClassDefFoundError:
> java.lang.management.ManagementFactory
> 12-04 21:34:41.639: WARN/System.err(23160): at
> org.apache.lucene.store.NativeFSLockFactory.acquireTestLock(NativeFSLock
> Factory.java:87)
> 12-04 21:34:41.639: WARN/System.err(23160): at
> org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactor
> y.java:142)
> 12-04 21:34:41.649: WARN/System.err(23160): at
> org.apache.lucene.store.Directory.makeLock(Directory.java:106)
> 12-04 21:34:41.649: WARN/System.err(23160): at
> org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1058)
>
> Turns out Android does not have
> java.lang.management.ManagementFactory.
>
> There are several work arounds in client code, but not sure what is best.
>
> The bigger question is whether and how Lucene should be modified to
> accommodate?
>
> Ultimately FSDirectory.open does the following:
> if (Constants.WINDOWS) {
> return new SimpleFSDirectory(path, lockFactory);
> } else {
> return new NIOFSDirectory(path, lockFactory);
> }
>
> Should Android be a supported client OS?
>
> If so, wouldn't it be better not to have OS specific if-then-else and use
> reflection or something else?
>
> Thanks,
> DM
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Exception in migrating from 2.9.x to 3.0.2 on Android
Posted by Robert Muir <rc...@gmail.com>.
On Sat, Dec 4, 2010 at 6:16 PM, DM Smith <dm...@woh.rr.com> wrote:
> Should Android be a supported client OS?
Not by lucene java, since Android isn't java.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org