On Thu, 10 Dec 2020 20:55:49 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? > >> 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/1679
