To solve warning incorrect classpath: src/checkstyle/target/test-classes on clean environment

Please explain suppress reason in javadoc.
Why IDEA does not have there suppression ? Is it a hug in Eclipse analyser?

I do not think this is a bug. The algorithms that use IDEA and Eclipse are different. And they can behave differently.

ok, call it new feature request, enhancement, any type of ticket against Eclipse to be better.
If IDEA found way to make less false positives, why Eclipse should be behind ?

If Eclipse is less configurable/smart ... why we should activate it ? Does it make sense to activate only IDEA ?
Do we get some benefit from Eclipse only(not detected by IDEA) ?

Please explain suppress reason in javadoc.

Please explain suppress reason in javadoc.

Please make comment more general. As we sometime postpone close for resource by design, not only for this particular case - Main.createListener

all done

sorry to enforce bureaucracy, but it is proven by practice, principle to do "done" for each point.
It is just final recheck that all items from numerous are done.

comment for myself.
from IDEA:

Reports AutoCloseable instances which are not used in a try-with-resources statement, also known as Automatic
Resource Management. This means that the open resource before/in try, close in finally style which was used
before try-with-resources was available is also reported. This inspection is meant to replace all opened but not
safely closed inspections when developing in Java 7 and higher.
Use the first table below to specify which AutoCloseable subclasses should be ignored by this inspection. Specify
AutoCloseable subclasses here which do not need to be closed.
Use the second table below to specify which methods returning AutoCloseable will be ignored when called.
Use the first checkbox below to ignore an AutoCloseable if it the result of a method call. When enabled, the results
of factory methods will also be ignored.
Use the second checkbox below to specify that the inspection should not warn if an AutoCloseable instance is
passed as a method call argument. If enabled the inspection assumes the resource is closed in the called method. Method calls inside a finally block with close in the name and an AutoCloseable argument will not be ignored.

Config for proposed xml looks like this in IDEA:

Yes, it is related to the ignoreFromMethodCall option.
By turning it off the IDEA reports the line

            out = Files.newOutputStream(Paths.get(outputLocation));

as violation in the same way as Eclipse does. One more: the suppression

    @SuppressWarnings("resource")

Works for IDEA in the same way as for Eclipse. So it is possible to set ignoreFromMethodCall to false.

this javadoc is public, let be more accurate here.

please remove "The JDT compiler issues the warning explicitlyClosedAutoCloseable ...." and make it like This method create in AuditListener open stream for validation data, it must be closed by {@link RootModule} (default implementation is {@link Checker}) by launching {@link AuditListener#auditFinished(AuditEvent)}

done

getValue

it is not ok. We can resolve this bad code.

please review commits, sorry if they are messy, I can not squash in main repo:
2b0ac1b
9c6aa47
I refactored createListener to create streams when required getOutputStream(outputLocation) and getOutputStreamOptions(String outputLocation).

If it still messy, I will recreate branch.
If you have some concerns with such implementation, we can merge this PR, but discuss update in separate issue.

done. Your code has been squashed to the PR.

Please move explanation on why stream is not closed to getOutputStream(String outputLocation) .
Unfortunately there is no way to keep reason of suppression in same annotation, so javadoc is only place to keep reason of suppression

done

incorrect indentation, -1 space

done

can we split all new lines so they are less than 100 characters where possible?

if this is not obvious how to make, we can postpone it for later.

done. If the CI fails, i'll revert this.

It fails: https://teamcity.jetbrains.com/viewLog.html?buildId=1439514&tab=Inspection&buildTypeId=Checkstyle_IdeaInspectionsPullRequest

The line wrapping reverted.

same.

if this is not obvious how to make, we can postpone it for later.

isn't this assertion unnecessary since eventually we will hit fail below? Also when can a new instance return null?

Without this assertion, the warning "The allocated object is never used" appears. See
https://travis-ci.org/checkstyle/checkstyle/jobs/378234050#L761
We need to use the logger somehow to make the eclipse compiler happy.

This won't work:

    @Test
    public void testNullOutputStreamOptions() {
        try {
            new XMLLogger(outStream, null);
            fail("Exception was expected");
        }
        catch (IllegalArgumentException exception) {
            assertEquals("Invalid error message", "Parameter outputStreamOptions can not be null",
                    exception.getMessage());
        }
    }

If you have any idea how to do it right, let us know.

happiness for all - is tough.
This nuance nobody will remember, it far from obvious.
What if we will put in assert message "Null instance; assert required to calm down eclipse's 'The allocated object is never used' violation" or just make single line comment above assert ?

What if we will put in assert message "Null instance; assert required to calm down eclipse's 'The allocated object is never used' violation" or just make single line comment above assert ?

done

This sounds familiar which we had to do with other tests.

same.

same

Why is this documentation needed when no code was changed? This is a test area.

yes, looks strange.

I believe that there was a suppression. Later, the code was refactored. The comment is removed now.

Just curious, why are we adding these IAEs and do we need them in other areas?

Pitest. It says "the result may be replaced with null here

    private static AutomaticBean.OutputStreamOptions getOutputStreamOptions(String outputLocation) {
        final AutomaticBean.OutputStreamOptions result;
        if (outputLocation == null) {
            result = AutomaticBean.OutputStreamOptions.NONE;  // THIS line was red
        }
        else {
            result = AutomaticBean.OutputStreamOptions.CLOSE;
        }
        return result;
    }

The expression

closeStream = outputStreamOptions == OutputStreamOptions.CLOSE;

work just fine when the parameter outputStreamOptions is null.
It turns out that we can use an enumeration with just one value! The second value will be null.
This is logical, but wrong. I explicitly forbid null for these parameters.