[GitHub] [maven-shared-utils] michael-o commented on a change in pull request #38: [MSHARED-894] deprecate close methods since we require Java 7+

[GitBox <gi...@apache.org>]

michael-o commented on a change in pull request #38:
URL: https://github.com/apache/maven-shared-utils/pull/38#discussion_r431875428



##########
File path: src/main/java/org/apache/maven/shared/utils/io/IOUtil.java
##########
@@ -43,41 +43,36 @@
  * copying between sources (<code>InputStream</code>, <code>Reader</code>, <code>String</code> and
  * <code>byte[]</code>) and destinations (<code>OutputStream</code>, <code>Writer</code>,
  * <code>String</code> and <code>byte[]</code>).
- * </p>
- * <p/>
+ * 
  * <p>Unless otherwise noted, these <code>copy</code> methods do <em>not</em> flush or close the
  * streams. Often, doing so would require making non-portable assumptions about the streams' origin
  * and further use. This means that both streams' <code>close()</code> methods must be called after
  * copying. if one omits this step, then the stream resources (sockets, file descriptors) are
  * released when the associated Stream is garbage-collected. It is not a good idea to rely on this
- * mechanism. For a good overview of the distinction between "memory management" and "resource
- * management", see <a href="http://www.unixreview.com/articles/1998/9804/9804ja/ja.htm">this
- * UnixReview article</a></p>
- * <p/>
+ * mechanism.</p>
+ * 
  * <p>For each <code>copy</code> method, a variant is provided that allows the caller to specify the
  * buffer size (the default is 4k). As the buffer size can have a fairly large impact on speed, this
  * may be worth tweaking. Often "large buffer -&gt; faster" does not hold, even for large data
  * transfers.</p>
- * <p/>
  * <p>For byte-to-char methods, a <code>copy</code> variant allows the encoding to be selected
  * (otherwise the platform default is used).</p>
- * <p/>
  * <p>The <code>copy</code> methods use an internal buffer when copying. It is therefore advisable
  * <em>not</em> to deliberately wrap the stream arguments to the <code>copy</code> methods in
  * <code>Buffered*</code> streams. For example, don't do the
  * following:</p>
- * <p/>
+ * <p>
  * <code>copy( new BufferedInputStream( in ), new BufferedOutputStream( out ) );</code>
- * <p/>
+ * </p>
  * <p>The rationale is as follows:</p>
- * <p/>
+ * 
  * <p>Imagine that an InputStream's read() is a very expensive operation, which would usually suggest
  * wrapping in a BufferedInputStream. The BufferedInputStream works by issuing infrequent
  * {@link java.io.InputStream#read(byte[] b, int off, int len)} requests on the underlying InputStream, to
  * fill an internal buffer, from which further <code>read</code> requests can inexpensively get
  * their data (until the buffer runs out).</p>
  * <p>However, the <code>copy</code> methods do the same thing, keeping an internal buffer,
- * populated by {@link InputStream#read(byte[] b, int off, int len)} requests. Having two buffers
+ * populated by {@link InputStream#read(byte[] b, int offset, int len)} requests. Having two buffers

Review comment:
       The original code refers to it as `off`.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org