Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of uwe@thetaphi.de designates
 85.25.204.22 as permitted sender)
From: "Uwe Schindler" <uwe@thetaphi.de>
To: <java-user@lucene.apache.org>
References: 
 <CAG-ePOb2D8-HFyhPvhtcAnuVTN7t-rZiiZqfvWTaiy_nVEAUvw@mail.gmail.com>
In-Reply-To: 
 <CAG-ePOb2D8-HFyhPvhtcAnuVTN7t-rZiiZqfvWTaiy_nVEAUvw@mail.gmail.com>
Subject: RE: Issues with lucene 4.10.0 on android
Date: Fri, 26 Sep 2014 09:09:24 +0200
Message-ID: <000001cfd958$ce070630$6a151290$@thetaphi.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQLeQbkLQsxHPmNAzOWNbwL2AJ+N2Jn2KpMQ
Content-Language: de

Hi
=20
> Background: My company has built an Android application that utilizes
> Lucene 4.7.0 to index and search upon a fairly static set of about =
100,000
> documents. We have used numerous versions of Lucene over the years, =
and
> they have all worked well to accomplish this purpose.
>=20
> Issue: Upon upgrading to Lucene 4.10.0, the application=E2=80=99s =
functionality broke.
> As it turns out, an exception named =
=E2=80=9Cjava.nio.file.NoSuchFileException=E2=80=9D is
> now utilized within the DirectoryReader class. This exception class is =
not
> available within the Android runtime, and the Dalvik VM crashes with =
an
> =E2=80=9Cunable to resolve exception=E2=80=9D error every time a =
DirectoryReader tries to
> open.

Lucene 4.8+ changed from Java 6 to Java 7 as minimum requirement. With =
this move, we initially changed the NIOFSDirectory and MMapDirectory =
Directory implementations to use Java 7's NIO2 to open index files =
(https://issues.apache.org/jira/browse/LUCENE-4848). The NIO2 API allows =
better error handling (see also =
https://issues.apache.org/jira/browse/LUCENE-5945). This better error =
handling use a more fine-granular exception handling with more =
informative errors if something goes wrong. So you *have* to use the new =
Exception types, otherwise you would break error handling. In 4.8, 4.9 =
and 4.10, Lucene's NIOFSDirectory and MMapDirectory implementations use =
NIO2 internally, so the new Exception types like NoSuchFileException are =
needed here.

> Possible Solutions: This problem could be remedied by replacing the =
usage of
> =E2=80=9Cjava.nio.file.NoSuchFileException=E2=80=9D with =
=E2=80=9Cjava.io.FileNotFoundException=E2=80=9D
> or simply an IOException. The suspect code exists in the =
=E2=80=9ClistCommits=E2=80=9D
> method of =E2=80=9CDirectoryReader.=E2=80=9D
> try {
>     sis.read(dir, fileName);
> } catch (NoSuchFileException | FileNotFoundException var10) {
>     sis =3D null;
> }
>=20
> Is this something you would consider changing to make it compatible =
with
> android?

Sorry, no step backwards. Instead, we went one step further: In Lucene =
5.0 - the version coming after 4.10.x - we did a complete cutover to =
NIO2, so all stuff around java.io.File is now forbidden APIs and are no =
longer used in Lucene (see =
https://issues.apache.org/jira/browse/LUCENE-5945). Everything in Lucene =
now uses java.nio.file.Path and java.nio.file.Files APIs (including =
virtual file systems).

Changing this Exception catch block to remove this exception would not =
help you, because you would get another error later, because NIO2 is =
missing on Android (as far as I know). Android is only partially Java 7 =
syntax compatible, but not API compatible at all - no APIs of Java 7 =
were implemented yet. They seem to be mostly compatible to Java 6, so =
you can only use Lucene 4.7.x with Android (no guarantees!!!)
=20
> Thanks in Advance,
>=20
> David

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org