[BEAM-4775] mv function pkg from fn-harness to java-core

[ryan-williams]

also: parameterize ThrowingConsumer by Exception type

This is factored out of #7823, where a use-case for a ThrowingConsumer<IOException, …> exists, in Jackson JSON serde code.

R: @robertwb, @mxm

Post-Commit Tests Status (on master branch)

Lang	SDK	Apex	Dataflow	Flink	Gearpump	Samza	Spark
Go		---	---	---	---	---	---
Java
Python		---			---	---	---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

[mxm]

Could you explain why this is necessary? I'm assuming it has to do with the dependency structure.

[ryan-williams]

Yea, sorry it's not clear. I need to think more about metrics/proto package-structures in #7823 that may affect this. Let me do that and circle back.

In the meantime, here's some context for the package-move, as it currently stands:

• in [DO NOT MERGE] [BEAM-4775] Second take on portable metrics over the job-server API #7823, I have a use for ThrowingConsumer in sdks/java/core
• it (and its friends) currently live in sdks/java/fn-harness
  • they don't have anything to do with the fn-harness
  • ideally, they'd be in java.util.function, or something like Guava; they don't have anything to do with Beam
• sdks/java/core seems the most logical place to put them that is accessible from sdks/java/core
  • I could also make a new module, and have java-core depend on that
    • However, that has all the downsides from a "lots of things now transitively depend on this" perpspective
    • It would keep things a bit more modular in general though, and leave the option to rearrange things later, better parallelize builds in the meantime, etc., so maybe that's worth doing.
  • It's also possible I can move the java-core metrics stuff to a different, less "core", package
    • Let me think about this for a bit, I need to think more about where all the Java SDK metrics stuff should live in [DO NOT MERGE] [BEAM-4775] Second take on portable metrics over the job-server API #7823 anyway.

parameterizing ThrowingConsumer's Exception`-type:

Context for the other part of this PR:

• I pass a JSON-serialization action as a lambda and need to encode that it throws IOException
• If the code that receives that lambda declares a generic throws Exception, then code that calls that would have to do some unwieldy catching/casting to go from Exception back to IOException.

[mxm]

Thanks for clarifying. I think moving them to the core makes sense.

[mxm]

What is the use case for this change? It looks like you only pass Exception as ExceptionT. Do you want to define contracts for other subclasses of Exception?

[ryan-williams]

There was a note at the end of this comment about that part.

It's not used here, but I do have a motivating case for a ThrowingConsumer<IOException, T> in #7823.

[ryan-williams]

I think this can be decoupled from metrics/module concerns, and is good to go, if you agree that java/core is a more logical place for such generic language-level helpers.

Even if the metrics code that uses it ends up somewhere higher-up than java/core, having it depend on these helpers in java/core seems reasonable.

Pulling things like this back out of java/core to dedicated packages later seems fine and good as well, if necessary.

[mxm]

Looks good. Thanks!