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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

<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


load_java_atk_wrapper.patch (3K) Download Attachment
signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

Fridrich Strba
Hello, good people,

I am answering this for those who might fall on the thread and feel like
it went hanging.

On 25/10/17 22:04, mandy chung wrote:
> 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.

I contacted the maintainer and am still waiting for the answer :(
Nevertheless, I went ahead and ported java-atk-wrapper to JDK 9. There
are two bugs in gnome bugzilla having my patches:

https://bugzilla.gnome.org/show_bug.cgi?id=789956 is having all the
patches that don't bump the required JDK to 9, but solve several issues
I met when I was porting it.

https://bugzilla.gnome.org/show_bug.cgi?id=789959 is having two patches,
one implementing the new provider and the other making j-a-w a module
called atk.wrapper.

I am also attaching minimal versions of the patches that allow just
build the java-atk-wrapper-0.33.2 tarball using the built jdk9 in our
RPM files. They don't allow build out of the tree and install has to be
done by "cp", but they work. This is the snippet that builds and
integrates it:

export JAVA_HOME=$(pwd)/%{buildoutputdir}/%{imagesdir}/jdk
....
pushd java-atk-wrapper-%{java_atk_wrapper_version}
autoreconf --force --install
rm wrapper/org/GNOME/Accessibility/AtkWrapper.java
%configure \
        --without-jdk-auto-detect \
        JDK_SRC=$JAVA_HOME
rm wrapper/org/GNOME/Accessibility/AtkWrapper.java
make %{?_smp_mflags}
cp wrapper/java-atk-wrapper.jar $JAVA_HOME/../jmods/
cp jni/src/.libs/libatk-wrapper.so $JAVA_HOME/lib/
popd
# Merge the java-atk-wrapper into the JDK
source $JAVA_HOME/release; export MODULES
$JAVA_HOME/bin/jlink --module-path $JAVA_HOME/../jmods --add-modules
"atk.wrapper,${MODULES//\ /,}" --output $JAVA_HOME/../newjdk
cp -rf $JAVA_HOME/../newjdk/* $JAVA_HOME/
rm -rf $JAVA_HOME/../newjdk

Needless to say that the patch patching the class loader is in the bin.

Thanks for your ideas

Fridrich

jaw-jdk9.patch (5K) Download Attachment
jaw-misc.patch (1K) Download Attachment
signature.asc (201 bytes) Download Attachment