search

apache / lucene

Apache Lucene open-source search software
https://lucene.apache.org/
Apache License 2.0
2.64k stars 1.02k forks source link

nio.Paths and nio.Files package are used in StringHelper, but they are restricted in many infrastructure and platforms [LUCENE-7036] #8093

Open asfimport opened 8 years ago

asfimport commented 8 years ago

nio.Paths and nio.Files package are used in StringHelper, but they are restricted in many infrastructure and platforms like Google App Engine. The use of Paths and Fiiles are not related to the main function of Lucene. It's better to provide an interface to store system properties instead of using File API in String Helper directly.

Migrated from LUCENE-7036 by Forrest Sun

asfimport commented 8 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Can you explain your problem? Lucene 5.x requires Java 7 at minimum and all file IO uses java.nio.files.* APIs. StringHelper uses the file /dev/urandom only if it is available. If the environment restricts access, another hasing is used.

asfimport commented 8 years ago

Forrest Sun (migrated from JIRA)

In Google App Engine and other Platform as Service infrastructure, They provide a layer of abstraction to manage storage. File IOs are restricted in many cases. And the services will present a class can not initialize error if users use these class.

asfimport commented 8 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

You won't be able to use Lucene at all without java.nio.file.* classes. In addition StringHelper catches SecurityExceptions and handles accordingly.

asfimport commented 8 years ago

Shawn Heisey (@elyograg) (migrated from JIRA)

I hope I'm relaying correct information here. This is my current understanding:

When using the standard directory implementation, Lucene has a fundamental dependency on the classes that you're asking about. This has been the situation since version 4.8.0, when Java 7 became the minimum. Before that version, Lucene used the File class for I/O. The switch to NIO2 has made Lucene a lot more stable.

If the abstraction layers you mentioned are specific to the service providers, changing this would make Lucene incompatible with off-the-shelf JVMs.

It might be possible to create your own Directory implementation that uses the abstraction layer provided by the service. If their license is compatible with the Apache license, that addition could be included in Lucene as a contrib module.