16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
52 lines
1.4 KiB
Plaintext
52 lines
1.4 KiB
Plaintext
== Why is this an issue?
|
|
|
|
In java 7 to 9, ``++FileInputStream++`` and ``++FileOutputStream++`` rely on finalization to perform final closes if the stream is not already closed. Whether or not the stream is already closed, the finalizer will be called, resulting in extra work for the garbage collector. This can easily be avoided using the ``++Files++`` API.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,java]
|
|
----
|
|
try(FileInputStream fis = new FileInputStream(...)) { // Noncompliant
|
|
} finally {
|
|
}
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,java]
|
|
----
|
|
try(InputStream is = Files.newInputStream(...)) {
|
|
} finally {
|
|
}
|
|
----
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Use "Files.newXXXStream" here instead for better performance.
|
|
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== on 21 Feb 2019, 11:32:51 Tobias Gruetzmacher wrote:
|
|
Since I just debugged an issue with that class, I'd propose to add ``++java.util.zip.ZipFile++`` to the "dangerous" classes with finalizer... Using an ``++java.util.zip.ZipInputStream++`` avoids the finalizer.
|
|
|
|
=== on 21 Feb 2019, 11:56:44 Alexandre Gigleux wrote:
|
|
Hello [~tobix],
|
|
|
|
Can you open a thread on \https://community.sonarsource.com/c/suggestions/rules so we can get more details about the problem you faced? It's much more convenient than using JIRA Comments.
|
|
|
|
Thx
|
|
|
|
endif::env-github,rspecator-view[]
|