Fix Java Access Bridge compatibility on 32 bit systems

[FelipeZanabria]

Link to issue number:

fixes #10842, fixes #16330

Summary of the issue:

When NVDA focuses a Java application on a 32-bit system, it gets stuck on the icon, without the ability to interact with it.

Description of user facing changes

When the user on a 32-bit system focuses on a Java application, the controls can be navigated normally, as was the case in version 2019.2.1 and earlier.

Description of development approach

• Check the architecture of the running system
• Based on this define the jobj64 class.
  • If the system is 64 bits use the type c_int64, otherwise use c_int.
  • Finally define which dll should be loaded. If the system is 64-bit, load WindowsAccessBridge-32.dll included in NVDA, otherwise load WindowsAccessBridge.dll, available in c:\Windows\System32.

Testing strategy:

Assuming the user has Java installed on a 32-bit system, simply search for Java in the start menu or control panel. When you find the configure Java element, press enter and move through it

Known issues with pull request:

None.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[AppVeyorBot]

• PASS: Translation comments check.
• PASS: Unit tests.
• FAIL: Lint check. See test results for more information.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/4gyqqk370bur9hv6/artifacts/output/nvda_snapshot_pr16557-31953,3d1837b1.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.2,
  INSTALL_END 1.0,
  BUILD_START 0.0,
  BUILD_END 31.7,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.4,
  TEST_START 0.0,
  TEST_END 2.4,
  FINISH_END 0.2

See test results for failed build of commit 3d1837b138

[AppVeyorBot]

• FAIL: Lint check. See test results for more information.
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.0,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 29.6,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.4,
  TEST_START 0.0,
  TEST_END 2.3,
  FINISH_END 0.2
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/17vhgbbd9osfsybb/artifacts/output/nvda_snapshot_pr16557-31955,833372aa.exe
• PASS: Translation comments check.
• PASS: Unit tests.

See test results for failed build of commit 833372aadc

[seanbudd]

given #16330, could you make this a system wide constant in winAPI.constants?

[seanbudd]

See also #16330 (comment), please use os.environ["PROCESSOR_ARCHITECTURE"].endswith("64")

[mwhapples]

What environment precisely is this other DLL to be used in? To clarify specifically what I am thinking, is it for a 32-bit OS environment where both NVDA and the Java runtime will be 32-bit, or is it for a 32-bit (java runtime regardless of the OS environment (IE. it is possible to run a 32-bit JRE on a 64-bit OS). Does this correctly detect the actual thing of concern or does it miss a case IE. if the DLL is to be used whenever a 32-bit JRE application is running, then detecting the OS architecture misses the case of 32-bit JRE on 64-bit windows). Can NVDA detect whether the application is a 32-bit or 64-bit process?

[AppVeyorBot]

• PASS: Translation comments check.
• PASS: Unit tests.
• FAIL: Lint check. See test results for more information.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/spkk5koadevgnhwq/artifacts/output/nvda_snapshot_pr16557-31973,95b6ced4.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.2,
  INSTALL_END 1.0,
  BUILD_START 0.0,
  BUILD_END 31.7,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.4,
  TEST_START 0.0,
  TEST_END 2.4,
  FINISH_END 0.2

See test results for failed build of commit 95b6ced447

[FelipeZanabria]

What environment precisely is this other DLL to be used in? To clarify specifically what I am thinking, is it for a 32-bit OS environment where both NVDA and the Java runtime will be 32-bit?

Yes.

[FelipeZanabria]

See nvaccess/javaAccessBridge32-bin#2

[seanbudd]

As requested earlier, given #16330, could you make this a system wide constant in winAPI.constants?

[josephsl]

Hi, if you want to know system architecture, do NOT use “PROCESSOR_ARCHITECTURE” environment variable as it will , if yoㅕsystem architecture, 애 NOT use PROCESSOR_ARCHITECTURE environment variable as it returns whatever the architecture is set for the current process only. In addition to making this an API constant, a much better method is winVersion.getWinVer().processorArchitecture.endswith(“64”), and this call will be useful for a while as we move toward 64-bit NVDA (see #16304). Thanks.

[seanbudd]

Thanks @FelipeZanabria, can you please pull in the latest changes from nvaccess/javaAccessBridge32-bin#2 and also update

nvda/projectDocs/dev/createDevEnvironment.md

Line 86 in e7e8233

* [Java Access Bridge 32 bit, from Zulu Community OpenJDK build 17.0.9+8Zulu (17.46.19)](https://github.com/nvaccess/javaAccessBridge32-bin)

[seanbudd]

Please also add a message to changes.md like this one

nvda/user_docs/en/changes.md

Line 205 in 57ce236

* Updated Java Access Bridge to 17.0.9+8Zulu (17.46.19). (#15744)

[josephsl]

Hi,

I see. While I'm not from NV Access, I would like to strongly recommend doing the following before contributing future pull requests:

1. UPGRADE TO (or BUY) Windows 10, preferably Version 22H2 (2022 Update/build 19045); or even better, if you are able, get a system with Windows 11 Version 23H2 (2023 Update) installed so you can be on the same page as most developers (NV Access folks included).
2. INSTALL Git LOCALLY! As you have learned, there are tasks requiring local Git on your computer (one important task is updating submodules).
3. If able, try setting up the local development environment as close to what NV Access folks and contributors are using (Python 3.11 32-bit, Visual Studio (or VS build tools) 2022, to name a few). You can use Git for Windows, or if you would like to do so, try using Windows Subsystem for Linux (WSL) with a distro such as Ubuntu with Git and other tools installed. You can also try using Visual studio Code for writing NVDA contributions.

The reason for recommending these (not merely suggesting them) is because you are using a setup that is not ideal (or even unusable/unacceptable) for software development - Windows 7 is no longer supported by Microsoft in any shape or form, and a failing (dying) hard disk means you need to be careful of what you are doing before the data (including contributions you are making) is gone; I would go further and get a new system as soon as possible or back up your data to somewhere safe if you intend to work on future NVDA contributions. Trust me when I advise you: the new system doesn't have to be a shiny computer with topmost specs - the system should meet your needs when doing various tasks, including coding, hopefully lasting several years. I thank you for taking our pull request review seriously and incorporating our feedback; at the same time, take our advice to heart when we recommend getting a system that can help you do many things for years to come.

Thanks.

[seanbudd]

Thanks, I'm going to apply some minor changes. When the final build completes, please do a final round of testing and then we can merge

[seanbudd]

@FelipeZanabria - can you test this build out: https://ci.appveyor.com/api/buildjobs/lxn6iv0md5en4cd8/artifacts/output%2Fnvda_snapshot_pr16557-32144%2C803cdcf3.exe

[seanbudd]

Some wider community testing would be also be welcome, for using Java Access Bridge Applications on various combinations of:

• 32/64bit system architecture
• 32/64bit software
• Windows 8.1, 10, 11

[FelipeZanabria]

@FelipeZanabria - can you test this build out: https://ci.appveyor.com/api/buildjobs/lxn6iv0md5en4cd8/artifacts/output%2Fnvda_snapshot_pr16557-32144%2C803cdcf3.exe

With my W7 it is impossible to test this snapshot, but 3 days ago when you updated the submodule, I checked if the two Java dlls were in the installer. They weren't there, so I looked in sconscript, and after seeing that the first dll was there, I added the last one, waited for the compilation and it was included there.
Also before publishing each commit I tested the changes in my setup.

[josephsl]

Hello Felipe,

Do you have access to a computer running Windows 8.1 or later, preferably Windows 10 22H2 (build 19045) or later? That way you can do a live test (running the modified NVDA executable) of the modifications from this pull request instead of doing compilation and library inclusion tests.

As I stated earlier, testing NVDA pull requests on Windows 7 is really questionable because NVDA 2024.1 and later (including the master branch code) does NOT support Windows 7 in any form or shape. This is an important thing to remember because the best way to see if your PR is working is doing live tests - running the modified NVDA with Java apps (with JAB applied) yourself. I think testing the inclusion of the library is a useful strategy on Windows 7, but by not considering live tests, the effectiveness and impact of the pull request is diminished (I'm sorry to say). So as I also stated, before writing another pull request, PLEASE get a system running updated Windows releases such as 10 and 11 so you can do live tests, improving the effectiveness and impact of pull requests.

Thanks.

[FelipeZanabria]

@josephsl I don't have it, but I'm going to write to the mailing list in Spanish inviting them to try the changes.

[josephsl]

Hi Felipe,

I see. Thanks for the pull request, and please do use Windows 10 or 11 yourself while writing the next pull request.

Thakns.

[Adriani90]

@mwhapples have you any chance to test this PR on some 32bit java applications on 32 / 64 bit systems?

At least on my Windows 11 on a 64 bit system it works well with the 64bit java configuration window which indicates that the java access bridge for 64 bit works aas expected, so this PR doesn't seem to have any effect on 64 bit.
So if we can test that for 32bit works as well, then I guess it should be fine.

[Adriani90]

I also tested with JRE 8.411 32bit, it still works fine on my 64 bit system.

So I think we need here testing on pure 32 bit systems I guess.

@FelipeZanabria do you have a test application we can test with? Or can you give some recommendations?

[FelipeZanabria]

I also tested with JRE 8.411 32bit, it still works fine on my 64 bit system.

So I think we need here testing on pure 32 bit systems I guess.

@FelipeZanabria do you have a test application we can test with? Or can you give some recommendations?

@Adriani90 Thanks for trying and commenting.
The Java control panel itself is enough, although I also tried the Linux sampler for Windows 32-bit.
https://download.linuxsampler.org/packages/win32/snapshots/linuxsampler_20240326_setup.exe
The installer covers both architectures, so you must have a 32-bit system for x32 to be installed. In the components to be installed, you must check Jsampler, which is the Java frontend application.

[seanbudd]

I don't have it, but I'm going to write to the mailing list in Spanish inviting them to try the changes.

@FelipeZanabria - can you link to this thread?
When we get testing confirmed with a 32bit system I think we can merge

[FelipeZanabria]

Here is the thread:
https://groups.google.com/g/nvda-es/c/2JwIUPg_Lo0
And:
https://groups.google.com/g/nvda-es/c/pko9MwD8b8s

[FelipeZanabria]

@seanbudd it seems that no one on the Spanish mailing list uses 32-bit Windows, except for one who also uses w7, which doesn't help moving forward.
Perhaps you could ask on the international mailing list.
What do you think? Could someone do it? Thank you.