Singletons should be used with caution and I don't think we want one
here, PDFBox would not be able to be used in a multi-threaded server
environment, which is currently the case. There must be a way to pass
either the color itself, the engine or the graphics state(probably the
best) to the methods that need it.
Ben
Daniel Wilson wrote:
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
