You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@beam.apache.org by Jan Lukavský <je...@seznam.cz> on 2023/10/13 16:59:31 UTC
[DISCUSS] Drop Euphoria extension
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/
Re: [DISCUSS] Drop Euphoria extension
Posted by Kenneth Knowles <ke...@apache.org>.
Makes sense to me. Let's deprecate for the 2.52.0 release unless there is
some objection. You can also look at the maven central downloads (I believe
all PMC and maybe all committers can view this) compared to other Beam jars.
Kenn
On Mon, Oct 16, 2023 at 9:28 AM Jan Lukavský <je...@seznam.cz> wrote:
> 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/
> >>
>
Re: [DISCUSS] Drop Euphoria extension
Posted by Kenneth Knowles <ke...@apache.org>.
Makes sense to me. Let's deprecate for the 2.52.0 release unless there is
some objection. You can also look at the maven central downloads (I believe
all PMC and maybe all committers can view this) compared to other Beam jars.
Kenn
On Mon, Oct 16, 2023 at 9:28 AM Jan Lukavský <je...@seznam.cz> wrote:
> 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/
> >>
>
Re: [DISCUSS] Drop Euphoria extension
Posted by Jan Lukavský <je...@seznam.cz>.
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/
>>
Re: [DISCUSS] Drop Euphoria extension
Posted by Jan Lukavský <je...@seznam.cz>.
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/
>>
Re: [DISCUSS] Drop Euphoria extension
Posted by Alexey Romanenko <ar...@gmail.com>.
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/
>
Re: [DISCUSS] Drop Euphoria extension
Posted by Alexey Romanenko <ar...@gmail.com>.
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/
>