Fix Javadoc errors, Error prone errors and most obvious warnings about jool HOT 9 CLOSED

1. I have tried hard to find the best "autocrlf" setting, but nevertheless I have probably missed it :-(
   (or You've missed it first – because all changed files have "true" LF now ;-). GitHub shows too many changes – this is because of different CrLfs. If you compare the files in IDEA, etc. – the situation is much less dramatic.

2. I hope, more than one commit in PR is ok :-(
   I've had [eb3bc6c] already, but then I decided, as they said, to "go beyond"

from jool.

Thanks for your suggestion. I'll reject this issue and the PR. It mixes many concerns, making a review impossible.

1. I have tried hard to find the best "autocrlf" setting, but nevertheless I have probably missed it :-(
   (or You've missed it first – because all changed files have "true" LF now ;-).

I'm fine with fixing this, but cleanly and thoroughly, not as a piggy backed huge change to something as simple as "a few javadoc errors"

Personally, I think it's simplest to just leave it as it is.

2. I hope, more than one commit in PR is ok :-(

Yes, but more than one topic isn't. Impossible to review.

from jool.

"report simple bugs showing what you think should be fixed"

It would flood your list here with similar quite stupid issues!

I could propose a "more compact" solution:

1. "Replace in files"
   * @see {@link
   -with-
   * {@link

2. Javadoc' DocLint wants tag CODE inside tag PRE, so
   Replace in files:
   <code><pre>
   -with-
   <pre><code>

</pre></code>
-with-
</code></pre>

</pre><code>
-with-
</code></pre>

from jool.

2. copy from my forked repo into your jOOL working dir subfolder jOOL (~ jOOL/jOOL where src folder is):
   a) gradle folder with two files gradle\wrapper\gradle-wrapper.properties and gradle\wrapper\gradle-wrapper.jar
   b) file jool\build.gradle
   c) file jool\gradle.properties

[i] Now ls must show:
build.gradle gradle/ gradle.properties pom.xml src/

and then simply run:

$ gradle build

You would see them all :-)

from jool.

I have just tried these steps on a fresh cloned repo:

2 errors
670 warnings

After fixing these two errors, you will go to the next game level:

javadoc errors and warnings

from jool.

Two so called compile errors are

1. jOOL\jOOL\src\main\java\org\jooq\lambda\Blocking.java:74: error: [ReturnValueIgnored] Return value of 'get' must be used return () -> supplier(() -> { runnable.run(); return null; }).get(); ^ (see https://errorprone.info/bugpattern/ReturnValueIgnored)

2. jOOL\jOOL\src\main\java\org\jooq\lambda\WindowImpl.java:587: error: [StreamToString] Calling toString on a Stream does not provide useful information return partition.cacheIf(completePartition(), "toString", () -> window().toString()); ^ (see https://errorprone.info/bugpattern/StreamToString)

from jool.

It would flood your list here with similar quite stupid issues!

Issue trackers are simple and focused. I may agree with your type variable fix (which I already implemented separately). I may not agree with your java 8 javadoc fix (because it's too time consuming and java 8 is quite near EOL). I certainly don't agree with huge "fixes" to whitespace, which make it very hard to review the rest.

Should we discuss a single PR back and forth 100 times just to exclude change X but include change Y? Or can we discuss simple units of work with a diff of 2-3 lines of code, which are no-brainers to merge, whereas others can be rejected simply from the discussion alone, without the need to spend time on creating a PR?

Two so called compile errors are

1. jOOL\jOOL\src\main\java\org\jooq\lambda\Blocking.java:74: error: [ReturnValueIgnored] Return value of 'get' must be used return () -> supplier(() -> { runnable.run(); return null; }).get(); ^ (see https://errorprone.info/bugpattern/ReturnValueIgnored)

That's a false positive, although I can see how static analysis would report it. It just proves that static analysis is flawed. You may report it to ErrorProne, or exclude it in your fork.

But I don't really want to spend time wrestling such false positives. It's too time consuming.

2. jOOL\jOOL\src\main\java\org\jooq\lambda\WindowImpl.java:587: error: [StreamToString] Calling toString on a Stream does not provide useful information return partition.cacheIf(completePartition(), "toString", () -> window().toString()); ^ (see https://errorprone.info/bugpattern/StreamToString)

That's an even worse false positive. jOOλ overrides Stream.toString() in a meaningful way (which is debatable, but it's there). But ErrorProne didn't detect that, and now reports this as an error. Another bug in ErrorProne.

Quite likely, a lot of your warnings are also false positives.

from jool.

<code><pre> invalid HTML has been addressed via #401. I don't get any error for * @see {@link, so I don't see the need for action here.

from jool.

#397 was fixed, thanks for that.

from jool.