[
https://issues.apache.org/jira/browse/BEAM-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634733#comment-16634733
]
Kenneth Knowles commented on BEAM-5526:
---------------------------------------
[~romain.manni-bucau] you've marked this as a "blocker" priority. It is an
implementation detail. {{DoFnInvoker}} and {{DoFnInvokerFactory}} are not
user-facing APIs. The reason there is an interface is due to good practice (see
Parnas
https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf).
You should put an interface in place when a significant decision is made, even
if there is only one implementation. Here, the interface is around the decision
of what library to use, just like you say.
It is kind of a cool idea to implement some other DoFnInvoker factories for
users, but then if the pipeline fails it is a user bug, not a Beam bug. That
might get confusing. Have you opened this idea on the dev list?
> Make ByteBuddyDoFnInvokerFactory injection strategy configurable + drop the
> singleton
> -------------------------------------------------------------------------------------
>
> Key: BEAM-5526
> URL: https://issues.apache.org/jira/browse/BEAM-5526
> Project: Beam
> Issue Type: Improvement
> Components: sdk-java-core
> Reporter: Romain Manni-Bucau
> Assignee: Kenneth Knowles
> Priority: Blocker
>
> org.apache.beam.sdk.transforms.reflect.DoFnInvokers + DoFnInvokerFactory
> design is to be a SPI to let user plug their own bytecode manipulation
> library, however in practise beam uses ByteBuddyDoFnInvokerFactory as a
> singleton which makes all this design useless.
> ByteBuddyDoFnInvokerFactory is also not configurable at all - typically the
> injection strategy so it assumes it runs in an environment and on a JVM where
> it will work - it does not on java 11 for instance.
> This ticket is about fixing all these small inconsistency and blocker to tun
> on java 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
