You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/11/29 16:46:00 UTC
[jira] [Work logged] (BEAM-6150) Provide alternatives to
SerializableFunction and SimpleFunction that may declare exceptions
[ https://issues.apache.org/jira/browse/BEAM-6150?focusedWorklogId=170705&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-170705 ]
ASF GitHub Bot logged work on BEAM-6150:
----------------------------------------
Author: ASF GitHub Bot
Created on: 29/Nov/18 16:45
Start Date: 29/Nov/18 16:45
Worklog Time Spent: 10m
Work Description: jklukas opened a new pull request #7160: [BEAM-6150] Superinterface for SerializableFunction allowing declared exceptions
URL: https://github.com/apache/beam/pull/7160
Also provides an equivalent superclass for SimpleFunction.
See https://issues.apache.org/jira/browse/BEAM-6150
The intention here is to be both binary and recompile compatible with code using previous version of the Beam Java SDK, so some careful review is needed to ensure that's the case. See the Java specification's chapter on [binary compatibility](https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html).
We originally discussed deprecating SerializableFunction and SimpleFunction in favor of the new classes, but there appear to be two fairly separate use cases for SerializableFunction. It's either defining user code that will be executed in a DoFn, in which case I think we always want to prefer the new interface that allows declared exceptions. But it's also used where the code is to be executed as part of pipeline construction, in which case it may be reasonable to want to restrict checked exceptions. In any case, deprecating SerializableFunction and SimpleFunction can be discussed further in the future.
I've attempted to provide significant context in the docstrings to explain the differences between these various classes and interfaces, and to explain the naming. The new interface and class are now used in `MapElements`, `FlatMapElements` and `Filter` as part of this PR. There are many other places in the SDK where we could alter methods to accept these less restrictive types, but those can be altered as needed in future changes.
I'm very open to feedback about suggestions for alternate names for the new `ProcessFunction` and `InferableFunction`.
------------------------
Follow this checklist to help us incorporate your contribution quickly and easily:
- [x] Format the pull request title like `[BEAM-XXX] Fixes bug in ApproximateQuantiles`, where you replace `BEAM-XXX` with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
- [x] If this contribution is large, please file an Apache [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
It will help us expedite review of your Pull Request if you tag someone (e.g. `@username`) to look at it.
Post-Commit Tests Status (on master branch)
------------------------------------------------------------------------------------------------
Lang | SDK | Apex | Dataflow | Flink | Gearpump | Samza | Spark
--- | --- | --- | --- | --- | --- | --- | ---
Go | [](https://builds.apache.org/job/beam_PostCommit_Go_GradleBuild/lastCompletedBuild/) | --- | --- | --- | --- | --- | ---
Java | [](https://builds.apache.org/job/beam_PostCommit_Java_GradleBuild/lastCompletedBuild/) | [](https://builds.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Apex_Gradle/lastCompletedBuild/) | [](https://builds.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Dataflow_Gradle/lastCompletedBuild/) | [](https://builds.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Flink_Gradle/lastCompletedBuild/) [](https://builds.apache.org/job/beam_PostCommit_Java_PVR_Flink/lastCompletedBuild/) | [](https://builds.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Gearpump_Gradle/lastCompletedBuild/) | [](https://builds.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Samza_Gradle/lastCompletedBuild/) | [](https://builds.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Spark_Gradle/lastCompletedBuild/)
Python | [](https://builds.apache.org/job/beam_PostCommit_Python_Verify/lastCompletedBuild/) | --- | [](https://builds.apache.org/job/beam_PostCommit_Py_VR_Dataflow/lastCompletedBuild/) </br> [](https://builds.apache.org/job/beam_PostCommit_Py_ValCont/lastCompletedBuild/) | [](https://builds.apache.org/job/beam_PostCommit_Python_VR_Flink/lastCompletedBuild/) | --- | --- | ---
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 170705)
Time Spent: 10m
Remaining Estimate: 0h
> Provide alternatives to SerializableFunction and SimpleFunction that may declare exceptions
> -------------------------------------------------------------------------------------------
>
> Key: BEAM-6150
> URL: https://issues.apache.org/jira/browse/BEAM-6150
> Project: Beam
> Issue Type: Improvement
> Components: sdk-java-core
> Reporter: Jeff Klukas
> Assignee: Jeff Klukas
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Contextful.Fn allows subclasses to declare checked exceptions, but neither SerializableFunction nor SimpleFunction do. We want to add a new entry in each of those hierarchies where checked exceptions are allowed. We can then change existing method signatures to accept the new superinterfaces in contexts where allowing user code to throw checked exceptions is acceptable, such as in ProcessElement methods.
> Discussed on the dev mailing list:
> https://lists.apache.org/thread.html/eecd8dea8b47710098ec67d73b87cf9b4e2926c444c3fee1a6b9a743@%3Cdev.beam.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)