Thanks all for the valuable feedbacks! @Gael @Dawid Thanks for the explanation! I think you are right that this discussion is about a non-instantiable class that contains only static methods.
@All My major proposal is actually to stick to one of two approaches in Flink. It seems that most devs prefer private constructor. And to be honest, I also could not see any drawbacks to that approach. All in all, we may choose the private constructor approach instead. If you think we should ban one of these two approaches, please +1 and tell your preferences. If you think we should not enforce it, please -1. Thanks for all the feedbacks again. Looking forward to your comments! Best, Yangze Guo On Fri, Sep 25, 2020 at 5:50 PM Jingsong Li <jingsongl...@gmail.com> wrote: > > Hi, thanks for starting this discussion. > > I am +1 for using the private constructor for util class. We don't need to > change it. > > I think few libraries use the enum, such as guava, common-utils, or even > JDK, the private constructor is widely used. > > I don't quite understand why a util class is an enum. Enum seems to be > conceptually different from general classes. It's just a util class, and I > don't want to enumerate it. > > And I think what Timo said makes sense to me. > > Best, > Jingsong > > On Fri, Sep 25, 2020 at 5:38 PM Timo Walther <twal...@apache.org> wrote: > > > Hi, > > > > honstely, I find using enums is more of a hack. `enum` stands for > > enumeration and is meant for listing flags or options. Using it for > > singleton patterns is just abusing a concept due to certain > > implementation details and less code. > > > > I feel this topic is like using Lombok for generating hashCode/equals. > > It means less coding but introduces another dependency and abuses the > > annotation processor. I would rather use the Java language according to > > the author's intention. > > > > Regards, > > Timo > > > > On 25.09.20 11:22, Piotr Nowojski wrote: > > > Hi, > > > > > > I don't mind one way or the other. > > > > > > I guess enum way is somehow safer, however did we really have any issues > > > with our current approach with `private` constructors? I mean, you are > > > mentioning that using reflections could overcome private constructors, > > but > > > is that a real concern in our code base? Has this caused some concrete > > > issues? If I would be reviewing a code doing things like this (or > > generally > > > speaking using reflections in the first place for anything), one should > > > better have a really good excuse :) > > > > > > So all in all, I would be +1 for allowing `Enum`, -0.1 for banning > > > `private` constructors approach, but I also wouldn't mind sticking with > > > `private` constructors for the sake of consistency if the majority of the > > > community has strong feelings against using enums. > > > > > > Piotrek > > > > > > pt., 25 wrz 2020 o 10:22 Yangze Guo <karma...@gmail.com> napisał(a): > > > > > >> Hi, devs, > > >> > > >> Recently, in the PR of FLINK-19179[1], we have a discussion about how > > >> to implement singleton pattern in Flink. > > >> > > >> Currently, most of the utility classes implement singleton pattern > > >> through the private constructor. Seldom utility classes leverage the > > >> enum mechanism. From my perspective, leveraging enum mechanism is more > > >> simple and it can also overcome reflection. > > >> > > >> Whether using enum classes or private constructors, it will be good to > > >> align the approach to achieve singleton in the whole Flink project. > > >> > > >> I would propose to leverage the enum mechanism in the Flink to > > >> implement singleton pattern and append it to the code-style > > >> guidelines. We may also have a JIRA ticket to refactor the existing > > >> code. > > >> > > >> What do you think? > > >> > > >> [1] https://github.com/apache/flink/pull/13416 > > >> > > >> Best, > > >> Yangze Guo > > >> > > > > > > > > > -- > Best, Jingsong Lee
