[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-awt-dev
Subject:    <AWT Dev> [PATCH] ComponentAccessor
From:       Artem.Ananiev () Sun ! COM (Artem Ananiev)
Date:       2009-01-20 14:44:54
Message-ID: 4975E366.90102 () sun ! com
[Download RAW message or body]

Hi, Roman,

Roman Kennke wrote:
> Hi Artem,
> 
>> the idea you're proposing is fine, actually so fine that we have already 
>> partly implemented it in the latest JDK6 update releases :) The fix 
>> itself is also fine from my perspective.
>>
>> Unfortunately, our implementation is slightly different - I'm not sure 
>> if you have access to 6u10/6u12 sources, though - so if we integrate 
>> your fix as proposed to OpenJDK, we'll have some troubles with upcoming 
>> merge with 6u10/6u12 codebase... The only thing I'd suggest for you now 
>> is to rewrite your fix using the same approach as we have.
> 
> Hrmpf. Is this fix in OpenJDK6 already? Then I should be able to grab
> the stuff and see what I can do. OTOH, I probably don't care so much
> about this then.

the changes I told about are not present in OpenJDK6 yet.

>> BTW, to save your (and our) efforts next time, it may be worth notifying 
>> everybody from this dev group about what you're going to start working 
>> on - probably, someone else has almost implemented this in other manner. 
>> This is by no means not a requirement, I'm just trying to avoid 
>> conflicts like this in the future.
> 
> Yeah, would be nice. I'm not sure how to do that though.
> 
> Speaking of this, I'd like to get rid of those many initIDs() methods in
> public AWT classes some day, because I don't need them in the peer impls
> that I have, but they force me to be implemented w/ empty stubs. That's
> quite ugly IMO and can be avoided in most cases by doing the JNI ID
> initialization in the peer code that's actually using them. I know that
> there's the class un-/reloading problem to be thought about, but in most
> cases that is not an issue (e.g. a XYZButtonPeer.initIDs() can safely
> init Button fields, because the Button class is not unloaded as long as
> the XYZButtonPeer class is unloaded, etc).

Right, initIDs look weird and should be moved to peer code when 
possible. However there are some cases when method IDs are stored for 
java.awt.* classes - see Java_java_awt_Font_initIDs() or 
Java_java_awt_FontMetrics_initIDs() for example. These cases should be 
carefully inspected and also moved to peer code.

Thanks,

Artem

> /Roman



[prev in list] [next in list] [prev in thread] [next in thread]