I could go too ways on this.
It looks like the code is looking to drop arrays that have grown so that
it doesn't waste memory. Do we reuse these objects? If not, then the
code can be deleted.
If we do reuse them, then why not just set them to null and let them get
recreated the next time r
Jeremy Manson wrote:
Does anyone have any thoughts about this? If we were to make up a
patch, would you take it?
In summary the situation looks like this, (although your dumps
aren't showing the locks, which I'd expected to see) :
Thread 1 -> SunGraphicsEnvironment.loadFonts()
Hi Roman,
Roman Kennke wrote:
Hi Dmitri,
a comment about the test: would the bug reproduce if you just rendered into a
BufferedImage? If so, no need for creating a frame and such.
Oh yes. Stupid me :-)
Regarding the fix, it looks ok - but there are other places in the code where
t
Hi Dmitri,
>a comment about the test: would the bug reproduce if you just rendered
> into a
> BufferedImage? If so, no need for creating a frame and such.
Oh yes. Stupid me :-)
>Regarding the fix, it looks ok - but there are other places in the code
> where
> the 'crossings' is acces
Hi Roman,
a comment about the test: would the bug reproduce if you just rendered into a
BufferedImage? If so, no need for creating a frame and such.
Regarding the fix, it looks ok - but there are other places in the code where
the 'crossings' is accessed - are those safe from an NPE?
Hi guys,
This patch here fixes the NPE in Pisces renderer as reported in:
https://bugs.openjdk.java.net/show_bug.cgi?id=100053
The webrev is here:
http://cr.openjdk.java.net/~rkennke/100053/webrev.00/
It basically adds nullchecks in the offending code. As far as I can see
this should be suffic
Does anyone have any thoughts about this? If we were to make up a
patch, would you take it?
I did get an email about how this should all be single threaded on an
event dispatcher thread, to which I would reply:
1) If it is all supposed to be single threaded, then there shouldn't
be any locks in
