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

Gary D. Gregory commented on IO-792:
------------------------------------

{quote}If the deprecated constructor `BOMInputStream(File file)` had something 
like `100% identical to BOMInputStream.builder().newFileOrigin(file)`, then it 
would be awesome.
{quote}
That won't even compile ;) 
See the Javadoc, reproduced here:
{code:java}
org.apache.commons.io.input.BOMInputStream


This class is used to wrap a stream that includes an encoded ByteOrderMark as 
its first bytes. 

This class detects these bytes and, if required, can automatically skip them 
and return the subsequent byte as thefirst byte in the stream. 

The ByteOrderMark implementation has the following predefined BOMs: 
•UTF-8 - ByteOrderMark.UTF_8
•UTF-16BE - ByteOrderMark.UTF_16LE
•UTF-16LE - ByteOrderMark.UTF_16BE
•UTF-32BE - ByteOrderMark.UTF_32LE
•UTF-32LE - ByteOrderMark.UTF_32BE

To build an instance, see Builder. 

Example 1 - Detecting and excluding a UTF-8 BOM

 BOMInputStream bomIn = BOMInputStream.builder().setInputStream(in).get();
 if (bomIn.hasBOM()) {
     // has a UTF-8 BOM
 }
 

Example 2 - Detecting a UTF-8 BOM without excluding it

 boolean include = true;
 BOMInputStream bomIn = BOMInputStream.builder()
     .setInputStream(in)
     .setInclude(include)
     .get();
 if (bomIn.hasBOM()) {
     // has a UTF-8 BOM
 }
 

Example 3 - Detecting Multiple BOMs

 BOMInputStream bomIn = BOMInputStream.builder()
   .setInputStream(in)
   .setByteOrderMarks(ByteOrderMark.UTF_16LE, ByteOrderMark.UTF_16BE, 
ByteOrderMark.UTF_32LE, ByteOrderMark.UTF_32BE)
   .get();
 if (bomIn.hasBOM() == false) {
     // No BOM found
 } else if (bomIn.hasBOM(ByteOrderMark.UTF_16LE)) {
     // has a UTF-16LE BOM
 } else if (bomIn.hasBOM(ByteOrderMark.UTF_16BE)) {
     // has a UTF-16BE BOM
 } else if (bomIn.hasBOM(ByteOrderMark.UTF_32LE)) {
     // has a UTF-32LE BOM
 } else if (bomIn.hasBOM(ByteOrderMark.UTF_32BE)) {
     // has a UTF-32BE BOM
 }
 
Since:2.0See Also:org.apache.commons.io.ByteOrderMarkWikipedia - Byte Order Mark
{code}
and:
{code:java}
org.apache.commons.io.input.BOMInputStream.Builder

Builds a new BOMInputStream instance. 

Using NIO  

 BOMInputStream s = BOMInputStream.builder()
   .setPath(Paths.get("MyFile.xml"))
   .setByteOrderMarks(ByteOrderMark.UTF_8)
   .setInclude(false)
   .get()
 

Using IO  

 BOMInputStream s = BOMInputStream.builder()
   .setFile(new File("MyFile.xml"))
   .setByteOrderMarks(ByteOrderMark.UTF_8)
   .setInclude(false)
   .get()
 
Since:2.12.0
{code}

> Add documentation how to migrate new BOMInputStream code
> --------------------------------------------------------
>
>                 Key: IO-792
>                 URL: https://issues.apache.org/jira/browse/IO-792
>             Project: Commons IO
>          Issue Type: Improvement
>          Components: Streams/Writers
>    Affects Versions: 2.12.0
>            Reporter: Vladimir Sitnikov
>            Priority: Major
>
> Recently, all the constructors of {{BOMInputStream}} got deprecated.
> It causes build failures when project lint for deprecation usages.
> See build failure in https://github.com/apache/jmeter/pull/5924
> The are three problems:
> P1) Unfortunately, in the case of {{new BOMInputStream}}, the API is obscure.
> The documentation merely says {{Deprecated Use builder()}}, and it is hard to 
> understand what is the right way to migrate old code.
> Imagine the build fails at the following line:
> {code:java}BOMInputStream fis = new 
> BOMInputStream(Files.newInputStream(fileEntry.file.toPath()));{code}
> What is the intended replacement?
> P2) {{BOMInputStream(final InputStream delegate, final boolean include, final 
> ByteOrderMark... boms)}} constructor is both deprecated and used in builder 
> internally.
> Is there a true reason for deprecating the method? Does it miss a vital 
> parameter?
> P3) Javadoc above {{class BOMInputStream}} still promotes {{new 
> BOMInputStream}} which is, well, deprecated.
> I would suggest:
> 1) Document deprecation reasons, and provide migration code.
> For instance, for constructors you could provide exact call to the builder 
> API instead of the current "use builder()"
> 2) Fix javadocs above {{BOMInputStream}}
> 3) Consider using ErrorProne annotations for automatic migration to the new 
> APIs: {{@InlineMe(replacement = "...")}}. It appears in javadocs, and it 
> makes it easier for the users to migrate (IDEs can migrate automatically): 
> https://javadoc.io/static/io.grpc/grpc-api/1.47.0/io/grpc/NameResolver.Listener2.html#onAddresses-java.util.List-io.grpc.Attributes-



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to