Hi Henry,
I'm going through unread emails and wasn't sure if I responded to this
before. Approved...
...jim
On 4/25/14 11:12 AM, Henry Jen wrote:
Thanks for the reviw.
On 04/23/2014 02:37 PM, Jim Graham wrote:
Shouldn't Order2, lines 50,77 be ""?
Ditto for Order3,
Thanks for the reviw.
On 04/23/2014 02:37 PM, Jim Graham wrote:
Shouldn't Order2, lines 50,77 be ""?
Ditto for Order3, lines 56,108?
I don't think we ever use these methods with any other type of Vector,
but I guess I can see that the choice you made might be a more general
choice.
Right, I
Shouldn't Order2, lines 50,77 be ""?
Ditto for Order3, lines 56,108?
I don't think we ever use these methods with any other type of Vector,
but I guess I can see that the choice you made might be a more general
choice.
This concludes my review of the geom files per Phil's request. They
look
Perhaps a simpler fix would be to return an empty Curve list there since
you can't have an enclosed area with fewer than 2 edges (even if it is a
curve, the segments are already broken up into monotonically
increasing/decreasing sections so no single curve segment can double
back on itself and
No, I think Henry got it right and it should have only been intending to
treat its return value as Vector...
...jim
On 4/7/14 4:13 PM, Joe Darcy wrote:
Hi Henry,
Thanks for looking into this. FWIW, while I was working on
JDK-8039109: Fix unchecked and raw lin
Given how vectors of curves are constructed, either they are the output
of a previous operation, in which case you need enough curves/edges to
enclose an area and the count must be 0 or >=2, or they are the result
of ingesting a Shape. Looking at the code that ingests a Shape in
Area.pathToCur
Ping.
The webrev is updated(rebase) to latest jdk9/client repo,
http://cr.openjdk.java.net/~henryjen/jdk9/8039342/1/webrev/
I also run Java2Demo with the result build and it seems fine.
Cheers,
Henry
On 04/09/2014 03:31 PM, Henry Jen wrote:
On 04/09/2014 02:35 PM, Phil Race wrote:
It seem
On 04/09/2014 02:35 PM, Phil Race wrote:
Yes it looks to be about 70% AWT and about 30% 2d ..
Remember there's a magic decoder ring at
http://openjdk.java.net/groups/2d/2dawtfiles.html
It may not have 100% coverage but it should help.
I looked over the 2D ones as below ..
src/share/classes/sun
Yes it looks to be about 70% AWT and about 30% 2d ..
Remember there's a magic decoder ring at
http://openjdk.java.net/groups/2d/2dawtfiles.html
It may not have 100% coverage but it should help.
I looked over the 2D ones as below ..
src/share/classes/sun/awt/FontConfiguration.java
src/share/cl
Thanks Joe for pointing out the request should go to awt-dev.
Cheers,
Henry
On 04/07/2014 04:13 PM, Joe Darcy wrote:
Hi Henry,
Thanks for looking into this. FWIW, while I was working on
JDK-8039109: Fix unchecked and raw lint warnings in java.awt
I started looking at some sun.awt.*
Thanks Joe for pointing out the review request ned to go to awt-dev.
Cheers,
Henry
On 04/07/2014 04:13 PM, Joe Darcy wrote:
Hi Henry,
Thanks for looking into this. FWIW, while I was working on
JDK-8039109: Fix unchecked and raw lint warnings in java.awt
I started looking at some su
Hi Henry,
Thanks for looking into this. FWIW, while I was working on
JDK-8039109: Fix unchecked and raw lint warnings in java.awt
I started looking at some sun.awt.* type too and I noticed the same
problem in AreaOp.pruneEdges(). The comment I added to my in-progress
webrev is:
203
Hi,
Please review the webrev cleans up raw and unchecked warnings in sun.awt,
http://cr.openjdk.java.net/~henryjen/jdk9/8039342/0/webrev/
The following changes in AreaOp::pruneEdges() is particular worth
attention, when numedges < 2, two different type are mixed up in the
past with use of raw
13 matches
Mail list logo
