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
