B'ccing discuss and core-libs as I realise this is mostly spam for those
lists.
On 3/28/2013 1:40 PM, Andrea Aime wrote:
On Thu, Mar 28, 2013 at 8:38 PM, Phil Race <philip.r...@oracle.com
<mailto:philip.r...@oracle.com>> wrote:
Maintaining a pool of objects might be an appropriate thing for an
applications,
but its a lot trickier for the platform as the application's usage
pattern or intent
is largely unknown. Weak references or soft references might be of
use but
weak references usually go away even at the next incremental GC
and soft
references tend to not go away at all until you run out of heap.
At the same time, the current decision is affecting some applications
badly.
I've seen the same happening for another old java2d bug, where the alpha
tile is cached and coordinated with JVM synchronized statement that
kill scalability in
server side applications heavily using Java2D (e.g, map servers):
http://bugs.sun.com/view_bug.do?bug_id=6508591
In fact that bug is not related to pisces, or the issue here.
its in the closed source ductus code which is native, not java.
For these kinds of decisions sometimes it's not possible to find a one
size that
fits all: it would be good if there was some way for the application
to plug-in their
own behavior, ideally with a Graphics2D rendering hint, less ideally
with a system
variable (a JVM can run multiple applications, not all might have the
same needs).
Now, I understand that today (java 7 or java 8) one could plug-in
their own rasterizer,
yet writing a rasterizer from scratch is kind of a tall order.
The pluggable interface wasn't so that others could do it, it was just
so that
JDK could operate with either pisces or ductus.
-phil.
Being able to get some control on these kind of decisions via hints
would be nicer imho.
Cheers
Andrea
