On Sat, 12 Dec 2020 18:59:39 GMT, Phil Race <p...@openjdk.org> wrote:

>>> Wouldn't it have been nice to have a new file having same JNF macros so it 
>>> will not result in changing any source code but just instead of mapping to 
>>> apple provided JNF layer, we will map to our macro through JNF wrapper and 
>>> link/unlink apple JNF lib based on version or so in makefile?
>> 
>> No. Not really. We should not keep the JNF namespace. Nor is there any 
>> desitre to have that 1:1 mapping.
>> This is NOT a "copy of JNF". It is a conscious attempt to be rid of it and 
>> all the unecessary baggage.
>> So I am not interested in that approach even one little bit
>
> I updated this fix with the additional changes for the accessibility files.
> There's a little bit of clean up as some declarations were unused and also 
> these files shared a single defintion of some classes across files which were 
> mostly unncecessary. One class I made static and declared per-file which is 
> cleaner,
> Also the only A11Y reference in AWTView was moved into its only call site.
> With these changes I think the desktop module is now 100% free of the 
> JNFCall* pattern and the *CACHE* pattern
> I re-ran our full automated headful jtreg test suite and everything passed. I 
> also ran VoiceOver and ran through SwingSet2 without seeing any issues 
> although I am not sure what to expect for this so it would be best if 
> @azuev-java checked it out.

Updated with some fixes for the A11Y support.
Adding some logging that will report any problems looking up a JNI method or 
field or class.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1679

Reply via email to