Timeline for What are the downsides of implementing a singleton with Java's enum?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 15, 2021 at 17:44 | comment | added | Metin Dagcilar | enum route is not simply about saving lines. It also protects you from having multiple instances of your singleton in the JVM and thus violating the singleton responsibility. Upon deserialization, if readResolve() is not overridden then a second instantiation of the singleton can be created. Secondly, using reflection a user can change the private constructor accessor visibility to public and create more instances. You can read more here dzone.com/articles/java-singletons-using-enum | |
| Aug 9, 2017 at 6:13 | comment | added | Divyesh Kanzariya | you also check this article : javatutorialspot.com/java/… | |
| Jul 17, 2015 at 19:17 | comment | added | Holger | @Kevin Krumwiede: the point is, that there is only one check within the Reflection code before the code goes into the internal implementation and there are other options of circumventing the check as long as you can use access override. As said, I don’t think that an “ironclad guaranty” is ever required, given what you can do when access override is not forbidden. So you have an ironclad but are sitting on a layer of ice… | |
| Jul 17, 2015 at 19:10 | comment | added | Kevin Krumwiede | @Holger You should probably report this as a bug. | |
| Jul 17, 2015 at 18:38 | comment | added | Holger | @Kevin Krumwiede: Constructor<?> c=EnumType.class.getDeclaredConstructors()[0]; c.setAccessible(true); EnumType f=(EnumType)MethodHandles.lookup().unreflectConstructor(c).invokeExact("BAR", 1);, e.g. a really nice example would be: Constructor<?> c=Thread.State.class.getDeclaredConstructors()[0]; c.setAccessible(true); Thread.State f=(Thread.State)MethodHandles.lookup().unreflectConstructor(c).invokeExact("RUNNING_BACKWARD", -1); ;^), tested under Java 7 and Java 8… | |
| Jul 17, 2015 at 18:36 | comment | added | Kevin Krumwiede | @Holger I'd like to see that. And I'm sure Josh Bloch would, too. | |
| Jul 17, 2015 at 7:56 | comment | added | Holger | @Kevin Krumwiede: actually, that “ironclad guarantee” turns out to be a simple check inside the Reflection API which can be circumvented by other reflection attacks. I just verified that, using the right code I could sneakily create an additional enum instance with just four lines of code. But anyway, what’s the point of that guaranty, if it existed? You can break any code using Reflection, so why should the singleton property of a class be excluded? In most cases, creating a second instance of such a class is the most harmless thing an attacker could do. | |
| May 31, 2015 at 17:54 | comment | added | Kevin Krumwiede | Using an enum saves a lot more than two lines of code. As noted in Effective Java item 3, this approach "provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks." | |
| Dec 14, 2012 at 16:10 | comment | added | scarfridge | Maybe we are not really talking about the same problem? | |
| Dec 14, 2012 at 16:08 | comment | added | scarfridge | Actually the linked discussion stresses my point. Let me explain what I understood as the problem you claim to exist. Some object A references a second object B. The singleton instance S references B as well. Now we deserialize a previously serialized instance of the enum-based singleton (which, at the time of serialisation, referenced B' != B). What actually happens is, that A and S reference B, because B' will not be serialized. I thought you wanted to express that A and S do not reference the same object anymore. | |
| Dec 14, 2012 at 15:25 | comment | added | irreputable | if an enum if stateful, serialization will lose state, deserialization will gain spurious state. | |
| Dec 14, 2012 at 15:24 | comment | added | irreputable | see this example of confusion: coderanch.com/t/498782/java/java/… | |
| Dec 14, 2012 at 15:15 | comment | added | scarfridge | -1: Your discussion of serialization is wrong. The mechanism is not simplistic as enums are treated very differently from regular instances during deserialization. The problem described does not occur as the actual deserialization mechanism does not modify a "state variable". | |
| Dec 14, 2012 at 2:34 | history | edited | irreputable | CC BY-SA 3.0 | added 115 characters in body |
| Dec 14, 2012 at 2:23 | history | edited | irreputable | CC BY-SA 3.0 | added 120 characters in body |
| Dec 14, 2012 at 2:17 | history | edited | irreputable | CC BY-SA 3.0 | added 120 characters in body |
| Dec 14, 2012 at 2:10 | history | edited | irreputable | CC BY-SA 3.0 | deleted 1 characters in body |
| Dec 14, 2012 at 2:02 | history | edited | irreputable | CC BY-SA 3.0 | deleted 1 characters in body |
| Dec 14, 2012 at 1:56 | history | answered | irreputable | CC BY-SA 3.0 |