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
