Yeah, that AWT code is changed almost exactly the same way. Don't know
why they kept Vector, could be AWT specific reason that doesn't apply to
FX. Uncontested synchronized blocks should however be practically free,
so I don't think it's worth doing more than copying their changes.
--John
On 30
You're right, these geometry classes were copied from AWT. Here is the
offending AreOp:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/geom/AreaOp.java
.
They generified their code at some point like John did. They also just
create a new vector in the 'numedges'
Probably derived from java.awt.Area:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/geom/Area.java
Le sam. 30 nov. 2024, 17:59, Nir Lisker a écrit :
> I agree with your type analysis. However, I'm hesitant to change the logic
> in regarding 'numedges' without
I agree with your type analysis. However, I'm hesitant to change the logic
in regarding 'numedges' without someone who is familiar with the domain
taking a look; these sorts of computations often have non-obvious sides to
them.
I also think that the class was copied. The raw types usage suggests a
Hi Nir,
I encountered that class before while doing raw warning clean-ups in
graphics (which were never integrated).
The problem IMHO is in the assignment in `calculate`:
edges = pruneEdges(edges);
This assignment is both confusing and unnecessary, and violates the
principle of re-using variabl
I came across a potential mistake in the class com.sun.javafx.geom.AreaOp.
It uses raw Vector types and while trying to add generic parameters there
for type safety, I got some conflicts.
In the method AreaOp::calculate, the arguments should be Vector and
the return type should also be Vector, but
