Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No X86 JAVA9 Access Bridge available might cause JAVA support issues for NVDA in future #7724

Closed
shadyar opened this issue Nov 3, 2017 · 28 comments · Fixed by #10515
Closed
Milestone

Comments

@shadyar
Copy link

shadyar commented Nov 3, 2017

Steps to reproduce:

as you know JDK v9 is produced only in 64-bit

  1. after installing JDK v9
  2. JAB switch is enabled.

Expected behavior:

NVDA should reads elements of the Java window.

Actual behavior:

but NVDA does not read elements.

System configuration:

NVDA version:
Version: next-14581,1014f6d4
NVDA Installed or portable: Installed
Windows version: Windows 10

Name and version of other software in use when reproducing the issue:

JDK v9 , and JRE v9

Other questions:

Does the issue still occur after restarting your PC?

Yes it does
Have you tried any other versions of NVDA?
No

@leonardder
Copy link
Collaborator

leonardder commented Nov 3, 2017

@shadyar commented on 3 nov. 2017 10:23 CET:

as you know JDK v9 is produced only in 64-bit

What makes you think this is the case? I have JRE 9 X86 here and it works pretty well.

@OzancanKaratas
Copy link
Contributor

OzancanKaratas commented Nov 8, 2017

I mentioned this problem on an issue, I think we can do with following changes:

Source: #7609
File: source / JABHandler.py

#Load the first available access bridge dll
legacyAccessBridge=True
try:
bridgeDll=getattr(cdll,'windowsAccessBridge-64')
legacyAccessBridge=False

Please open a try-jabswitch64 branch, we should try this code there.

@leonardder
Copy link
Collaborator

leonardder commented Nov 8, 2017

windowsAccessBridge-64 won't work with NVDA, as NVDA is, and will probably remain, x86.

@shadyar: Could you please answer my #7724 (comment) ? I'm afraid I have to close this as invalid otherwise.

@leonardder
Copy link
Collaborator

leonardder commented Nov 8, 2017

Hmm, seems you are right, according to this Stack Overflow thread . It seems I was one of these lucky ones mentioned in this thread.

CC @michaelDCurran, @feerrenrut, @jcsteh

Would it be possible to convince Oracle to ship WindowsAccessBridge-32.dll, I wonder. I guess not, since they never shipped that DLL with the X64 jre. Other options might be:

  • Just advice people to stick with JAVA 8
  • Make people use JAVA 9 for X64 and JAVA8 for x86 applications. This might work, but should be tested
  • Build an X86 version of WindowsAccessBridge-32.dll ourselves, if we could
  • Proxy all JAB stuff using NVDAHelper

@leonardder leonardder changed the title it's seams it's Time to Generate NVDA 64-bit No X86 JAVA9 Access Bridge available might cause JAVA support issues for NVDA in future Nov 8, 2017
@OzancanKaratas
Copy link
Contributor

OzancanKaratas commented Nov 8, 2017

May this file be used? This file is containing a C codes. I think it is able to compiled for supporting 64-bit architecture.

@Brian1Gaff
Copy link

Brian1Gaff commented Nov 9, 2017

@shadyar
Copy link
Author

shadyar commented Nov 10, 2017

@leonardder
#7724

hi
Leonardder, I do not know how you use JRE v9 x86 due to it has not been published by Oracle as an official final version. it seems JRE & JDK are published only for x64 machines
take a look at these pages
official JDK download page
official JRE download page

@Adriani90
Copy link
Collaborator

Adriani90 commented Nov 12, 2017

what restricts the NVDA project to become a 64bit software as well? The problem would be solved and NVDA would be equiped for future projects since there will be less and less applications in 32 bit.

@josephsl
Copy link
Collaborator

josephsl commented Nov 12, 2017

@Brian1Gaff
Copy link

Brian1Gaff commented Nov 12, 2017

@Brian1Gaff
Copy link

Brian1Gaff commented Nov 12, 2017

@Adriani90
Copy link
Collaborator

Adriani90 commented Nov 12, 2017

I found a very interesting discussion on this here:

https://portableapps.com/node/24371

Why can NVDA not become a hybrid version?
Alternatively, in case a hybrid version is not feasible, nowadays we don't have really big problems with respect to enough storage on a stick anymore. Sticks with even 32 gb can be bought for 15 USD or cheaper. So why not having the possibility to install 64bit and 32bit versions of NVDA on a stick?

@Brian1Gaff
Copy link

Brian1Gaff commented Nov 13, 2017

@mwhapples
Copy link
Collaborator

mwhapples commented Jun 11, 2018

Unfortunately, like it or not, sometimes Java swing applications are unavoidable, despite how bad we may feel java access bridge is in practice. Android Studio is one such example.

Suggesting users keep Java8 for a 32-bit bridge is not a long term solution as Oracle will be dropping support for it soon.

The best work around I can see for now is for users who must use Java swing applications to use alternative OpenJDK builds from companies such as Azul https://www.azul.com/downloads/zulu/ who offer Windows 32-bit and 64-bit builds of the JDK. Unfortunately in the case of Azul Zulu, it will mean users will need to manually install from ZIP files.

The above though is really a work around and it would be a far better user experience if NVDA could actually just make use of the 64-bit Java access bridge without needing a 32-bit bridge as well.

@Adriani90
Copy link
Collaborator

Adriani90 commented May 1, 2019

I thought always that some older 32bit java aplications would expose information only to the 32bit java access bridge. Or not? What is the current status of this now with the newer Java version?

@Qchristensen
Copy link
Member

Qchristensen commented Aug 7, 2019

Report from a user of another use case impacted here (because of Java 9) is developing for Android which requires Android Studio which requires uses Java 9 64-bit.

@thgcode
Copy link
Contributor

thgcode commented Sep 3, 2019

Hello,
I have examined the source code of the WindowsAccessBridge Java DLL on Java 8 and I tested that if I copy the WindowsAccessBridge32.dll from a x86 build of Java 8 it works on a 64 bit JVM, because the interaction is done on the JVM side and not in the WindowsAccessBridge DLL itself.
Maybe this can help a bit with this problem. If this DLL just passes messages between JVM and NVDA then it might be possible to include it on the NVDA folder and newer Java versions could work. The problem would be when the Java team modifies this DLL and no x86 version can be built, but this could be a temporary workaround.

@thgcode
Copy link
Contributor

thgcode commented Sep 3, 2019

Update:
It seems that the WindowsAccessBridge32.dll from Java 8 works on newer Java VMS.
I tested it now with Java 12 x64 and it worked.

@jcsteh
Copy link
Contributor

jcsteh commented Nov 19, 2019

I've had to look into this myself, since I need to use Android Studio.

The simple technical solution is for us to ship WindowsAccessBridge-32.dll with NVDA. The problem in the past was that the Oracle binary license prevents this. Now we have OpenJDK (GPL v2), but the problem now is that there are no 32 bit builds of newer versions.

Today, I created a sconstruct to build just the 32 bit Java Access Bridge from the OpenJDK sources:
https://github.com/jcsteh/javaAccessBridge32
The repository pulls in the OpenJDK GitHub mirror as a Git submodule. Then, you just run scons and end up with build/WindowsAccessBridge-32.dll.

The question is: how do we want to ship this with NVDA? I don't think pulling in the OpenJDK submodule for every build is feasible, as the checkout is over 1 gb. Do we want to just shove it in miscDeps or do we want a separate binary repo containing just the single dll? @michaelDCurran, thoughts?

@feerrenrut
Copy link
Member

feerrenrut commented Nov 19, 2019

@jcsteh Not that you asked me, but personally I would prefer a separate binary repo. It makes it harder to get in a tangle when updating the dependencies and makes it easier to document the process for creating / updating each of the dependencies. I think it also makes it easier to see what the dependencies are.

@jcsteh
Copy link
Contributor

jcsteh commented Nov 19, 2019

@leonardder
Copy link
Collaborator

leonardder commented Nov 19, 2019

I think it makes sense if you could provide the sconstruct file for reference in the binary repo. though it won't be uset, it might make it much easier to update the build if needed.

@feerrenrut
Copy link
Member

feerrenrut commented Nov 19, 2019

I think it makes sense if you could provide the sconstruct file for reference in the binary repo

Instead, the readme can just refer to the repo by @jcsteh which has everything necessary: https://github.com/jcsteh/javaAccessBridge32 Perhaps we should have our own fork.

@mwhapples
Copy link
Collaborator

mwhapples commented Nov 19, 2019

There are 32-bit builds of OpenJDK for Windows from Azul Systems https://www.azul.com/downloads/zulu-community/?&os=&os=windows&architecture=x86-32-bit&package=jre

The JRE community build in the above link contains WindowsAccessBridge-32.dll and the Zulu community builds are free to download and use without restrictions.

Seems like here is the binary which needs to be bundled with suitable licensing, no compiling, no need to download 1GB+ of repositories, etc.

Sorry I don't get why this is so difficult. I mentioned Azul zulu builds before and this is why I don't get why more complicated/involved solutions are being considered. Have I missed something?

@jcsteh
Copy link
Contributor

jcsteh commented Nov 19, 2019

@mwhapples: sorry, I seem to have missed the significance of your comment. I probably saw it briefly, but wasn't sure about the licensing or similar at the time. (Being able to download and use it as a whole without restrictions is very different to pulling part of it out and bundling it with something else, which is the problem we've had in the past with the JAB. We really don't want users to have to install this; it's much simpler if we can bundle it.)

Anyway, I agree this is a simpler solution, although the download size isn't really a huge factor here (it's still ~190 mbvs ~390 mb for the Git download; both take up even more space when extracted). I wish I'd dug into your comment sooner; I could have saved myself a few hours. :)

So we just need to extract the binary, shove it in a repo, add a quick readme about where it came from, and submit a PR to NVDA to include it as a submodule and use it. We should probably also drop support for the legacy JAB in JABHandler, since it won't be usable once this is bundled.

@jcsteh
Copy link
Contributor

jcsteh commented Nov 19, 2019

Scrap that; this build is only 40 mb. Not sure why the official OpenJDK builds are so much larger.

@feerrenrut
Copy link
Member

feerrenrut commented Nov 20, 2019

While it would have been nice to have avoided doing the work to get it building in the first place, the benefit for us now (thank you @jcsteh !) is that we aren't dependent on an external party. Though I have just noticed that you have used the DLL from Azul zulu instead. I assume this is to do with the size's you mentioned in your last comments?

@jcsteh
Copy link
Contributor

jcsteh commented Nov 20, 2019

@nvaccessAuto nvaccessAuto added this to the 2019.3 milestone Nov 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.