On Mar 12, 2019, at 21:10, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Ok, 3 getSingleton methods, one for each case, synchronized. First one wins. Subsequent ones throw an exception, since you can't have more than one.
This doesn’t smell good to me.
One should be able to have multiple references to a singleton, as long as there is only one singleton. Consider the use of ABCL in a Java Servlet context where each instance of the servlet is processing a separate, parallel request. Each such Servlet begins its lifecycle by getting a reference to the singleton ABCL instance, and then calling into ABCL to service the request.
Maybe you meant “three create singleton methods, synchronized”? This is similar to what we have now, using an exception rather than returning a null on failure. This would be a breaking change for existing users of the interface, as they would have to change their code to deal with the exception (unless we throw something that inherits from RuntimeException which would be even worse). Philosophically, Java exceptions should not be used for anticipated failures, as they are not potentially restartable like Common Lisp conditions.