lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENE-7036) nio.Paths and nio.Files package are used in StringHelper, but they are restricted in many infrastructure and platforms
Date Fri, 19 Feb 2016 22:43:18 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15155029#comment-15155029
] 

Shawn Heisey edited comment on LUCENE-7036 at 2/19/16 10:43 PM:
----------------------------------------------------------------

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.



was (Author: elyograg):
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, and such an addition could be included in Lucene as a contrib
module.


> nio.Paths and nio.Files package are used in StringHelper, but they are restricted in
many infrastructure and platforms
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-7036
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7036
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/other
>    Affects Versions: 5.1, 5.2, 5.3, 5.4, 5.5
>            Reporter: Forrest Sun
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message