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



##########
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:
       Fair enough. It's a link so reverted




----------------------------------------------------------------
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:
us...@infra.apache.org


Reply via email to