Hi Fridrich,
The maintainer of java-atk-wrapper was informed of the new
javax.accessibility.AccessibilityProvider service interface during JDK 9
development. java-atk-wrapper will need to implement a provider of
AccessibilityProvider to run on JDK 9 [1].
Adding to Phil's comment, java-atk-wrapper can become a modular JAR.
Alternatively it can deploy as a service provider on classpath by
including a service configuration file under META-INF/services/ [2]
I suggest you to contact the library maintainer to get a version of
java-atk-wrapper that supports JDK 9.
Mandy
[1]
https://docs.oracle.com/javase/9/docs/api/java/awt/Toolkit.html#getDefaultToolkit--
[2] https://docs.oracle.com/javase/9/docs/api/java/util/ServiceLoader.html
On 10/25/17 12:33 PM, Phil Race wrote:
I don't think patching ClassLoader files is a good idea and the folks
that own
ClassLoader are extremely unlikely to endorse anything like it.
Have you looked at javax.accessibility.AccessibilityProvider ?
It was designed with providers like ATK partly in mind.
See https://bugs.openjdk.java.net/browse/CCC-8055160
You must create a ServiceProvider for your AT extending
this class and make it a module - that is just a jar with a
module-info.java file which
in your case should have the line
"provides javax.accessibility.AccessibilityProvider with
org.GNOME.Accessibility.AtkProvider"
.. the latter being whatever you decide to name your provider class
which extends
AccessibilityProvider"
You aren't quite done yet.You will need to ensure it is on the module
path
for this you'll need jlink.
Think of this as being the equivalent of dropping it into the ext
directory.
jlink --module-path jdk9/jmod:atkmod --add-modules <your module> <AND
ALL JDK MODULES> --outputdir newjdk
But I don't know the incantation to get all JDK modules. Mandy may
know ..
The conf/accessibility.properties file should also reference it if you
want it to be always loaded .. eg
assistive_technologies=ATK.
The docs on java.awt.Toolkit explain this.
-phil.
On 10/25/2017 05:53 AM, Fridrich Strba wrote:
Hello, good people,
For some time, since openjdk was released, we have used as accessibility
provider java-atk-wrapper that wraps around the GNOME accessibility
toolkit. The java-atk-wrapper is composed from a jar file
java-atk-wrapper.jar and a native library libjava-atk-wrapper.so that
the java code loads. It was then possible to simply put the
java-atk-wrapper.jar into the extension directory and specify in
accessibility.properties the class org.GNOME.Accessibility.AtkWrapper as
assistive_technologies. The jar file being in extension directory, the
class was found and world was wonderful.
What really was wonderful is that the folks that need the accessibility
enabled needed only to install a package and the thing was working.
There was no need to do any lengthy configuration for them before they
could use Java applications.
Naturally, this changed when the extension mechanism was discontinued
with openjdk9. Moreover, if the class org.GNOME.Accessibility.AtkWrapper
is specified in accessibility.properties, but cannot be found, program
ends with ClassNotFoundException. Therefore, we tried to add to the
accessibility.properties another property, we called it
assistive_technologies.classpath, where we specified the place where the
jar file was located. Now, we needed to find where one can read the
property and how to pass it to the corresponding class loader. First we
tried to add this property to the system java.class.path property in
java.awt.Toolkit.initAssistiveTechnologies, but it was too late, because
the class loaders that use this property have already read it at this
time.
So, we decided to patch the jdk.internal.loader.ClassLoaders so that
this property is considered before the internal class loaders are
instantiated. We are reading the assistive_technologies.classpath
property from the same files and in the same order as the
java.awt.Toolkit.initAssistiveTechnologies does. Besides that, we are
checking whether the file that was specified in the property exist in
order not to pollute the class path with inexistent elements. If we
decided not to do that, the assistive_technologies.classpath could be
actually a real class path with several directories/jar files in it. But
not sure we want it here.
Now, this patch works in the sense that the class is loaded. This brings
the org.GNOME.Accessibility.AtkWrapper from a state of being virtually
useless to a state where it is loaded as it was with jdk9 and jdk7
before. It also has the advantage of not doing any complicated ugly
hacks setting private fields using reflection. Not speaking about the
fact that the jdk.internal module is not accessible anyway.
I am not sure whether I will be officially and publicly stoned if I
propose this upstream. Nevertheless, I would love someone in the know to
check the patch, criticize it and propose improvements.
I know it is too long to read, but I wanted to give context so that one
understands what we are actually trying to achieve.
Cheers
Fridrich
