<AWT Dev> java-atk-wrapper accessibility and openjdk9

mandy chung mandy.chung at oracle.com
Wed Oct 25 20:04:00 UTC 2017


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
>>
>



More information about the awt-dev mailing list