JDK-8196681 : Java Access Bridge logging and debug flags dynamically controlled
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.accessibility
  • Affected Version: 8u162,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-02-02
  • Updated: 2019-12-08
  • Resolved: 2018-12-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 8 Other
11.0.5-oracleFixed 13 b03Fixed 8u221Fixed openjdk8u232Fixed
Related Reports
CSR :  
JDK-8215722 - Java Access Bridge logging and debug flags dynamically controlled
Relates :  
JDK-8225805 - Java Access Bridge does not close the logger
Relates :  
JDK-8219914 - Change the environment variable for Java Access Bridge logging to have a directory
Description
This is a request for API change to Java Access Bridge to log the 
important steps for debugging purposes. We need the possibility to switch on 
and off dynamically logging for debugging.
Comments
[~akasko] It's not clear from the fix-request comment whether the patch was reviewed and got approved. It appears [~zgu] approved it. Next time please state the review status in the fix request comment.
22-11-2019
Fix request: Backport to 8u is requested because it's a part of 8u221-oracle. No regressions (tested with JAWS screen reader). Patch does not apply cleanly. 8u RFR: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010242.html 8u CSR (filed for JDK-8219914, also covers this issue): JDK-8231121
28-10-2019
Review thread for 8u-dev backport: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010242.html
17-09-2019
Fix request: Backport requested because it's part of Oracle 11.0.5. Patch applies cleanly. No regressions (tested at SAP).
13-06-2019
NOTE: This Bug fix will be retargeted to "13" in case this issue is still Unresolved by Mon, Dec 10 3am Pacific Time Mon Dec 10 (Pre Integration Testing deadline) to meet JDK 12 RDP1 (Dec 13th) milestone [1]. No more Enhancements in JDK 12 beyond RDP1 in accordance with RDP1 definition [2]. [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-September/001984.html [2] http://openjdk.java.net/jeps/3
29-04-2019
falls under the umbrella of being a part of that JDK-8219914 bug
26-04-2019
Reminder: Dec 13 is a deadline (JDK 12 RDP1) to push a code of Enhancement into mainstream repo before JDK 12 repo fork
27-11-2018
For testing/debugging purposes, do the following: 1. Define the environment variable "JAVA_ACCESSBRIDGE_LOGFILE", and have it point to any filepath, that can be writable. 2. Apply the patch: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/open.patch to local jdk ws and build it. 3. Copy the windowsaccessbridge-64.dll file from the built jdk/bin folder to C:\Windows\System32 folder. Make sure, you take a backup of any existing file with the same name. 4. Run the command "jabswitch.exe -enable", for the Java version on which the test is intended to be run. 5. Install JAWs, and start it up. 6. At this point, you should be able to see a file name <file-name>_windows_access_bridge<ext> being created/opened for writing. This should confirm that JAWs picked up the latest dll. 7. Run the test case and check that the log file is generated in the location given. Sometimes, due to buffering, the file size may appear to be 0. If this is the case, then close the test to see that the file is indeed getting written out. 8. To see the contents in <file-name>_windows_access_bridge<ext> updated, close JAWs and then check the file. Attaching the sample file generated on my local environment.
26-11-2018
Here is the example code that was used to test the feature: import javax.swing.*; public class AccessibleJTableTest { private static void runTest() { JFrame frame = new JFrame("AccessibilityTest"); frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); JTable table = new JTable( new String[][]{{"ONE", "TWO"}, {"FIVE", "SIX"}, {"MORE", "LESS"}}, new String[]{"Cleanup", "Run"}); table.getAccessibleContext().setAccessibleName("Hello funny table"); frame.getContentPane().add(new JScrollPane(table)); frame.pack(); frame.setVisible(true); } public static void main(String[] args) { SwingUtilities.invokeLater(AccessibleJTableTest::runTest); } }
14-09-2018
The proposed solution is to have the user/developer define an environment variable ���JAVA_ACCESSBRIDGE_LOGFILE��� and filling with the path to the log file. The JavaAccessBridge will read the variable, and write to the file in the path provided. Note that the implementation is simplistic, and doesnot have any way to handle multiple applications, since it is a debug only feature. Here is the link to webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/
13-09-2018
There are two ways to accomplish this task: 1. Maintain the file object in java side, and have the native logging function call back into java. But this requires the function signature to be changed in the native side, to pass the environment, and the AccessBridge object, so that correct function is called into java. 2. Maintain the file object in native side. This requires minimal changes since all the places where the logging function is called doesnot need to be changed, but we may need to store a static file-pointer object, and we may not be able to do PrivilegedAction kind of checks.
28-08-2018