I should have read that article more carefully the first time. The problem I feared very definitely exists. So I'm not checking this code in!
Alternate solutions anybody? Thanks! On Thu, Apr 23, 2009 at 7:20 PM, Daniel Wilson < [email protected]> wrote: > I have accomplished what I needed by borrowing from the Singleton idea, my > pattern being > http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html > > I have a private variable called instance, a public getInstance() method > that checks whether it's instantiated and returns it, and the constructors > are now protected. > > But it's not a true Singleton because the descendants (PageDrawer, > PDFTextStripper, etc.) still have public constructors. > > In a single-threaded environment, I don't think that matters. I think it > is practically a singleton in those situations. > > But what about a multi-threaded environment? > > class AlmostSingleton{ > private static AlmostSingleton instance; > protected AlmostSingleton(){ > instance = this; > } > public AlmostSingleton getInstance(){ > if (instance == null) instance = new AlmostSingleton(); > return instance; > } > } > > class Child1 extends AlmostSingleton{ > public Child1() { > //do whatever in constructor > } > } > > Now ... if 2 different threads instantiate Child1 and call getInstance(), > are they looking at the same instance or different ones? > > If the same, my static getInstance() causes a real problem. > > Making the descendants of PDFStreamEngine have private / protected > constructors would break a lot of client applications. Obviously we can't > go there. > > > On Thu, Apr 23, 2009 at 2:10 PM, Daniel Wilson < > [email protected]> wrote: > >> I am working through the implementation details of making PDFStreamEngine >> a singleton. >> >> I would like to do so because I need for the PDXObjectImage to be able to >> get the current nonstroking colorspace. >> >> The call >> *CS = >> PDFStreamEngine.getInstance().getGraphicsState().getNonStrokingColorSpace(); >> * >> would solve this very nicely. >> >> My understanding is that there is really only one PDFStreamEngine (or >> descendant thereof) in existence (within a particular thread's context) >> anyway. >> >> Does anyone see a problem with making PDFStreamEngine a singleton? A big >> theoretical problem, a reason it should not be attempted? >> >> I think I can work through the implementation details, as I said. And I >> will certainly run the junit tests to make sure the thing behaves in all our >> defined scenarios. >> >> Thanks! >> >> Daniel Wilson >> > >
