Sure, that would be probably the preferred way to go. For now, I'm
trying to get some feedback, if there are some real-world users who
might miss the API. Currently, the only value I see is that Euphoria
adds an additional level of indirection for user code. The expansion
goes like this:
Euphoria Pipeline -> runtime provided translators -> vanilla Beam
Pipeline -> runner
Hence code written using Euphoria extension can be modified at runtime
(Pipeline construction time) using dependency injection, which brings
the value that users can modify (typically optimize) Pipelines without
actually modifying the business logic. On the other hand I'm not sure if
this justifies the complexity of the extension. Were this the only
value, it should be possible to implement such dynamic expansion either
into Java SDK core or as a different light-weight extension.
Jan
On 10/16/23 15:10, Alexey Romanenko wrote:
Can we just deprecate it for a while and then remove completely?
—
Alexey
On 13 Oct 2023, at 18:59, Jan Lukavský <je...@seznam.cz> wrote:
Hi,
it has been some time since Euphoria extension [1] has been adopted by Beam as a possible
"Java 8 API". Beam has evolved from that time a lot, the current API seems
actually more elegant than the original Euphoria's and last but not least, it has no
maintainers and no known users. If there are any users, please speak up!
Otherwise I'd like to propose to drop it from codebase, I'll start a vote
thread during next week, if there are no objections.
Best,
Jan
[1] https://beam.apache.org/documentation/sdks/java/euphoria/
