Roman,
7) at the same class.
You wrote:
+ // TODO: Maybe change this to force Graphics2D, since many things will
+ // break with plain Graphics nowadays.
+ Graphics getGraphics();
Do you know a scenario to show what's exactly might be broken.
Many modern applications do stuff like this:
public void paint(Graphics g) {
Graphics2D g2d = (Graphics2D) g;
g.doFancyStuff();
}
This will break when we let peers return plain Graphics objects. I don't
have specific examples, but from my time as GNU Classpath developer I
know that quite alot of applications do the above thing, without
checking type. Even the Java2D/Swing tutorials from Sun advertise this.
The thing is that the official API in java.awt.Component only says
java.awt.Graphics, and that has probably been left that way for eternal
backwards compatibility ;-) We can't change this, but we can change the
internal peer interface.
Thanks for that clarification.
We
probably need to introduce another peer for that, right?
No, why?
Oh, please ignore that. You described that pretty clear.
Regards,
Andrei
8) Similar to 7):
+ // TODO: Maybe make that return a BufferedImage, because some stuff
will
+ // break if a different kind of image is returned.
+ Image createImage(int width, int height);
Yeah, the answer is similar to 7 too: there are many apps out that
expect exactly this behaviour, so we should probably give them what they
want. Can't change the public API, but we can change the peers.
The rest is just fine!
Finally I've applied the patch and reviewed the webrev. It was just more
convenient for me.
There was an exception for ComponentPeer.java - it caused some conflicts
and I didn't succeeded to resolve them fast enough so just looked on the
patch itself for that file.
At last the JDK7 workspace was successfully built.
Cool. I'll do the suggested changes and post another webrev for final
review.
/Roman
