Hi Kirk
PR with making constructors deprecated since 4.1.0 is ready to merge ->
https://github.com/apache/kafka/pull/18977.
wt., 25 mar 2025 o 01:24 Kirk True napisał(a):
> Hi Paweł,
>
> We can't change the existing (public) constructors to private in 4.1 as
> that would break users. Yes, we ca
Thanks for the pointer.
It seems the example would require to make the constructor of
`ConsumerGroupMetadata` package private though? If it's `private` as in
the example, `retyrb kafkaConsumer.groupMetadata()` would not be able to
return an instance, as the object is created inside `KafkaConsu
I double checked everything and unfortunately even when I created internal
and external representation of ConsumerGroupMetadata, this did not help.
The reasons why are as follows:
1. ConsumerCoordinator is evaluating the onAssignment method from
ConsumerPartitionAssignor which is a public in
@mj...@apache.org you can see an example in `Rejected Alternatives` section
in KIP (ConsumerGroupMetadata newInstance(KafkaConsumer kafkaConsumer
method).
I agree with you that making the class an inner class of `KafkaConsumer` is
quite big change and making ConsumerGroupMetadata an interface is g
and providing a static create method that takes a kafka consumer
object as a parameter or we can make the ConsumerGroupMetada inner not
static class in KafkaConsumer
Can you elaborate on the "static create method" -- frankly, it sounds a
little bit clumsy to me?
I guess we could make the clas
Using an interface is less effective than making the constructor private
and the class final though.
Ismael
On Mon, Mar 24, 2025, 9:12 PM Chia-Ping Tsai wrote:
> hi All,
>
> > Matthias J. Sax 於 2025年3月5日 凌晨4:20 寫道：
> >
> > To me, the main thing is really, that currently user can call `new` wha
hi All,
> Matthias J. Sax 於 2025年3月5日 凌晨4:20 寫道：
>
> To me, the main thing is really, that currently user can call `new` what
> makes it easy to do thing wrong. If we change it to an interface, users
> cannot call `new`, and if the interface says "do not implement me", it should
> hopefully t
Hi Paweł,
We can't change the existing (public) constructors to private in 4.1 as that
would break users. Yes, we can argue that users shouldn't be instantiating the
ConsumerGroupMetadata in the first place, but as of 4.0 those constructors are
part of the published API.
For 4.1, at most we co
mj...@apache.org any update on that? Can we release it in 4.1.0?
pt., 7 mar 2025 o 09:08 Paweł Szymczyk
napisał(a):
> mj...@apache.org the main point is that this class is a regular data
> structure, there is no way to give an alternative implementation which is
> the purpose of interface in Ja
mj...@apache.org the main point is that this class is a regular data
structure, there is no way to give an alternative implementation which is
the purpose of interface in Java. We can completely eliminate the
possibility of creating an instance of this class in any other way than via
Kafka Consumer
Reversing the question. What is the problem with using an interface? It
seem, and interface would provide the cleanest way to separate public
and internal things? Or maybe I misunderstand what you propose?
We can for sure not have a `private` constructor.
We can also not have "package private"
Hi,
Thanks for the KIP. Why did we reject the alternative where the constructor
is unavailable to external users?
Ismael
On Tue, Feb 25, 2025 at 8:27 AM Paweł Szymczyk
wrote:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1136%3A+Make+ConsumerGroupMetadata+an+interface
>
> --
> Pozd
Hi Matthias,
You're right and I agree with your comments.
Paweł—I'm happy with the KIP given Matthias’ points.
Thanks,
Kirk
On Tue, Mar 4, 2025, at 12:20 PM, Matthias J. Sax wrote:
> Hi,
>
> I think it should be sufficient to just state in the JavaDocs of the new
> interface, that the interfa
Hi,
I think it should be sufficient to just state in the JavaDocs of the new
interface, that the interface is not intended to be implement by users,
and point to the Consumer method that returns it.
To me, the main thing is really, that currently user can call `new` what
makes it easy to do
Hi Kirk
Many thanks for very good questions!
KT1. I don't think that internal implementation should totally prevent of
passing alternative implementation, but for sure we need to log warning
when producer receives different than default implementaion. I think that
checking internally is the class
Hi Paweł,
Thanks for the KIP!
My questions:
KT1. What will prevent developers from implementing their own
ConsumerGroupMetadata and passing that to sendOffsetsToTransaction()? I assume
the code will check the incoming object is of type DefaultConsumerGroupMetadata?
KT2. To me, the use of the
16 matches
Mail list logo
