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

[Phil Race]

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
>