[
https://issues.apache.org/jira/browse/LUCENE-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975069#comment-15975069
]
Hoss Man commented on LUCENE-7789:
--
NOTE: I have not audited our own code to see how much of an impact the
finalizers are likely to have in actual lucene/solr application instances, nor
done any investigation into how feasible doing this sort of replacement would
be given that in some cases I know we're using FileInputStream and
FileOutputStream specific methods like "getChannel" ... not sure if there are
related improvements in the "Files" class for dealing with those usecases w/o
involving a finalizer.
> replace & forbid "new FileInputStream" and "new FileOutputStream" with
> Files.newInputStream & Files.newOutputStream
> ---
>
> Key: LUCENE-7789
> URL: https://issues.apache.org/jira/browse/LUCENE-7789
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Hoss Man
>
> I haven't looked into the details of this much, but saw these links today and
> thought it would be worth opening a jira for discussion...
> *
> https://dzone.com/articles/fileinputstream-fileoutputstream-considered-harmful
> * https://issues.jenkins-ci.org/browse/JENKINS-42934
> * https://bugs.openjdk.java.net/browse/JDK-8080225
> The crux of the issue being that the "FileInputStream" and "FileOutputStream"
> classes have finalizer methods with GC overhead that can be avoided using
> Files.newInputStream and Files.newOutputStream in their place.
> This seems like it would make these methods good candidates for forbidding in
> lucene/solr (if possible).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
