nested throwingFunction() doesn't work on AdoptOpenJDK

[garretwilson]

This is likely a bug in the OpenJDK, but I wanted to report it first here to see if you could give me a more definitive direction to investigate further, as well as indicate a workaround.

I'm using org.zalando.faux-pas.0.8.0 with OpenJDK 11 on Windows 10:

openjdk 11.0.5 2019-10-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)

I have a section of code that looks like this. Note that it has nested FauxPas throwingFunction(), although I don't know if the nesting has anything to do with it.

//look for a per-page navigation definition file in the form `.filename.ext.navigation.*`
final Optional<Stream<NavigationItem>> pageNavigationDefinition = pageFilename.flatMap(throwingFunction(filename -> {
  final Set<String> navigationFilenames = SUPPORTED_NAVIGATION_FILE_EXTENSIONS.stream()
      .map(ext -> addExtension(DOTFILE_PREFIX + filename + navigationBaseName, ext)).collect(toCollection(LinkedHashSet::new));
  return findAncestorFileByName(sourceDirectory, navigationFilenames, Files::isRegularFile, sourceDirectory)
      .map(throwingFunction(file -> loadNavigationFile(context, contextArtifact, file)));
}));

That compiles just fine on Eclipse 2019-12 (4.14.0). But on AdoptOpenJDK I get this:

unreported exception java.io.IOException; must be caught or declared to be thrown

This error refers to the following line from the code above, because loadNavigationFile() throws an IOException.

.map(throwingFunction(file -> loadNavigationFile(context, contextArtifact, file)));

This same problem occurs in another location, inside a throwingFunction() that is wrapped in a throwingSupplier().

Should this code be allowed? Which is correct here: the Eclipse compiler or the OpenJDK compiler?

And do you know of a workaround, apart from splitting the code sections out and making the stream logic harder to read?

[garretwilson]

Interesting; this doesn't seem to be related to the nesting of FauxPas methods. I removed a throwingFunction() with a temporary workaround of catching and throwing an UncheckedIOException, and AdoptOpenJDK gives me the same error on the same line:

//look for a per-page navigation definition file in the form `.filename.ext.navigation.*`
final Optional<Stream<NavigationItem>> pageNavigationDefinition = pageFilename.flatMap(filename -> {
  try {
    final Set<String> navigationFilenames = SUPPORTED_NAVIGATION_FILE_EXTENSIONS.stream()
        .map(ext -> addExtension(DOTFILE_PREFIX + filename + navigationBaseName, ext)).collect(toCollection(LinkedHashSet::new));
    return findAncestorFileByName(sourceDirectory, navigationFilenames, Files::isRegularFile, sourceDirectory)
        .map(throwingFunction(file -> loadNavigationFile(context, contextArtifact, file)));
  } catch(final IOException ioException) {
    //TODO replace with FauxPas.throwingFunction() when OpenJDK supports it; see https://github.com/zalando/faux-pas/issues/144
    throw new UncheckedIOException(ioException);
  }
});

So maybe it's something to do with the depth of nesting of streams and lambdas? I want to emphasize that this compiles fine on Eclipse 2019-12 (4.14.0).

[garretwilson]

I've made two commits (in Bitbucket) so that you can see exactly what I'm talking about.

The first commit compiles on Eclipse but not on OpenJDK, as described above.

https://bitbucket.org/globalmentor/guise/commits/d16b0478d1225bc02b6f37d737f9735cb3169018

The OpenJDK errors are:

[96,89] unreported exception java.io.IOException; must be caught or declared to be thrown
[105,109] unreported exception java.io.IOException; must be caught or declared to be thrown
[112,79] unreported exception java.io.IOException; must be caught or declared to be thrown

The second commit provides the workaround:

https://bitbucket.org/globalmentor/guise/commits/4e6b92b7cf6baf632d00df2615794d3079cb9e13

[whiskeysierra]

Interesting!

Faux Pas relies on Lombok's @SneakyThrows which is essentially just a read-to-be-used version of what could also be crafted by hand. See https://www.baeldung.com/java-sneaky-throws

I suspect that this ability to cheat the compiler into believing you're throwing an unchecked exception while it is in fact a checked exception might not work in your environment anymore. I'm also using AdoptOpenJDK, but for MacOS. Seems to work just fine though.

[whiskeysierra]

I just double checked again and I'm able to successfully run the build in the following configurations:

• Java 1.8, target 1.8
• Java 11, target 1.8
• Java 11, target 11

They all work on MacOS. My AdoptOpenJDK version is:

java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)

I can not reproduce it.

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.