Hi Mehdi,

Guava is a really nice library, but what exactly is the issue(s) you would like 
to address with it ? Any stack traces ?

If you refer to the recently opened bz #53685, then this seems like a 
problematic selection of the cache key and not a concurrency problem. I don't 
think Guava would help there. If the creation of CharacterSetBuilders is not 
thread safe, why don't you just protect it with a synchronised block or a Lock 
? java.util.concurrent was a quite powerful addition in Java 5. In general, I 
would justify adding a runtime dependency whose size is comparable to FOP's 
size, if there are issues that can't be resolved equally well by writing a few 
lines of code. Or, if you intend to refactor FOP's internal data structures and 
Guava would help to reduce the amount of code, the number of bugs and increase 
readability. 

Alex Giotis


On Aug 9, 2012, at 11:59 AM, mehdi houshmand <med1...@gmail.com> wrote:

> Hi All,
> 
> I've come across a yet another concurrency based bug in FOP, this time to do 
> with how we handle AFP character-sets. The problem in this scenario is that 
> the CharacterSetBuilders are singletons and their creation wasn't really 
> intended to be used in a heavily multithreaded system. As such, we don't 
> really have a good implementation of a thread-safe cache for caching 
> expensive-to-create objects.
> 
> That's the problem I'm looking to solve, and the solution? Guava. The Guava 
> libraries [1] (under Apache 2.0 license) have well tested, intuitive classes 
> that do a lot of the low-level mechanisms that we often need, and there's 
> really no point in reinventing the wheel. The obvious cost of adding this 
> library is the addition of a JAR in the class-path, as such I'm not calling 
> for a vote at this point, I just wanted to know what the general consensus on 
> this was. The Guava library is often heralded as "the new Apache Commons" and 
> praised for being well maintained [2][3] but I'd suggest if anyone is 
> sceptical of the benefits, to do some research. I accept, however, that 
> developers can get a religious zeal about these kind of things, I'm not 
> suggesting Guava is the cure to world poverty, just that it could help handle 
> some of the lower-level tools. Though I'd love to spend time implementing 
> fit-for-purpose mechanisms, these issues are usually bugs that our clients 
> want fixed NOW!!! And so we find ourselves constantly saying "ok, we'll do it 
> this way for now, but next time we'll find a proper fix"...
> 
> This is a subject I've been wanting to bring up for a while, we've had to 
> implement several thread-safe caching systems (for example in the 
> pdf-image-plugin) but I wanted to wait for compelling reason. Though the 
> reason above isn't any more compelling than for the pdf-image-plugin, I think 
> the addition of this library would prevent some of the low-level mistakes 
> that we all make sometimes.
> 
> If anyone has questions, I'd be happy to explain my motivations in further 
> detail.
> 
> Mehdi
> 
> [1] http://code.google.com/p/guava-libraries/
> [2] 
> http://stackoverflow.com/questions/1444437/apache-commons-vs-guava-formerly-google-collections
> [3] 
> http://stackoverflow.com/questions/4542550/what-are-the-big-improvements-between-guava-and-apache-equivalent-libraries
> 

Reply via email to