[jira] [Commented] (BEAM-5526) Make ByteBuddyDoFnInvokerFactory injection strategy configurable + drop the singleton
[ https://issues.apache.org/jira/browse/BEAM-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635093#comment-16635093 ] Romain Manni-Bucau commented on BEAM-5526: -- [~kenn] I didnt open a thread on the list but the fact to have an interface for a single implementation leads to adding noise to the source code (which is what "papers" opposed to your pdf say and I agree with them more than this pdf from my past experience). What I like with it being pluggable is that engine would provide it and reuse their own asm flavor (xbean for instance in several of them) which would drop bytebuddy from beam dependencies. That said my immediate issue is that on java11 beam fails - i didnt find an umbrella ticket but I think there is one since it was discussed on the 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 >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)
[jira] [Commented] (BEAM-5526) Make ByteBuddyDoFnInvokerFactory injection strategy configurable + drop the singleton
[ https://issues.apache.org/jira/browse/BEAM-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16634737#comment-16634737 ] Kenneth Knowles commented on BEAM-5526: --- Do we have an umbrella ticket for Java 11? Is there a dev thread about tracking it? > 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 >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)
[jira] [Commented] (BEAM-5526) Make ByteBuddyDoFnInvokerFactory injection strategy configurable + drop the singleton
[
https://issues.apache.org/jira/browse/BEAM-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
