[
https://issues.apache.org/jira/browse/BEAM-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
