Why not getNumberOfViolations? Then the whole javadoc could be dropped.

Hello. I updated the location of @deprecate tag and change the method name to getNumberOfViolations and remove javadoc

I updated the location of @deprecate

But did you read the article I linked to? I mean javadoc @deprecated tag, especially

The @deprecated description in the first sentence should at least tell the user when the API was deprecated and what to use as a replacement.

Oh I see. I updated the java doc of the @deprecated tag

I updated the java doc of the @deprecated tag

Cool. But you still missed:

An @see tag (for Javadoc 1.1) or {@link} tag (for Javadoc 1.2 or later) should be included that points to the replacement method

Which - assuming meaning of getNumViolations is well-established (supposedly it's only me, but I will know since now as well - additional points for if the int return type is not explicit enough) is unnecessary. Like for referenced isEmpty method.

I don't really understand this paragraph. What are you saying is unnecessary?

I think eg a comment like the following is simple enough and doesn't repeat content:

/**
 * Returns the number of reported violations. 
 * This is the number of elements yielded by the {@link #iterator()} method. 
 */

The clarification for the confusion is kind of implicit, by just describing what the method returns in plain English, rather than making a separate sentence.

Btw the isEmpty method would IMO also need a javadoc to clarify what it does. It's not just the plain isEmpty you'd find on a List<RuleViolation>, since it also checks the number of errors. Just relying on the name here, you could write

if (!report.isEmpty()) {
 RuleViolation first = report.iterator().next();
}

and get a NoSuchElementException if there are only errors.

I don't really understand this paragraph. What are you saying is unnecessary?

Then I meant javadoc. (My fault of writing sentence too complex for myself.)

Your comment for that new method seems very fine.

^{Btw the isEmpty method would IMO also need a javadoc to clarify what it does.}

^{So is the name correct? But let's not discuss it here and now, as it's not its review.}

I think getNumX is such a well-known convention that there's hardly any ambiguity. Eg in JDK 10, there are 322 179 method declarations with this pattern, versus 55 for getNumberOfX. It's also used more in our own sources (19 vs 6).

So true inconsistency/free-style in JDK alone...
ColorSpace.getNumComponents vs. MouseInfo.getNumberOfButtons. Thanks for pointing to Sun. I'm glad I've never used AWT.
But I won't sleep well. 😞

Is there any changes needed from my side on this pull request? Thanks

@pdhung3012 Well after reviewing the Report API in #1962, and assuming we follow through on it, this PR won't be needed, as size() would be deprecated with no replacement anyway. Until we decide on it, this PR can be considered on hold.