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

[Fridrich Strba]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: load_java_atk_wrapper.patch
Type: text/x-patch
Size: 3055 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20171025/75f378b5/load_java_atk_wrapper.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20171025/75f378b5/signature.asc>