<AWT Dev> java-atk-wrapper accessibility and openjdk9
mandy.chung at oracle.com
Wed Oct 25 20:04:00 UTC 2017
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 .
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/ 
I suggest you to contact the library maintainer to get a version of
java-atk-wrapper that supports JDK 9.
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
> .. the latter being whatever you decide to name your provider class
> which extends
> You aren't quite done yet.You will need to ensure it is on the module
> for this you'll need jlink.
> Think of this as being the equivalent of dropping it into the ext
> 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
> The docs on java.awt.Toolkit explain this.
> 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
>> 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.
More information about the awt-dev