java-atk-wrapper accessibility and openjdk9

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

java-atk-wrapper accessibility and openjdk9

Fridrich Strba
Hello, good people,

Since the OpenJDK 9 removed the extension system, I was -- on and off --
thinking how to fix the java-atk-wrapper based accessibility. I wanted
to achieve something similar to what many distro packagers do for all
versions up to 8. Having a package of symlinks and
accessibility.properties file that tells the Java ATK which assistive
technologies to use. I wanted something that would be activated when the
package is installed and would have the normal behaviour when not.

I came with the attached patch.

Basically, it is enough to put into the accessibility.properties file a
property "assistive_technologies_classpath" pointing to the
java-atk-wrapper.jar and it will be added to the system property
java.class.path. It looks like it is done enough early for the
classloader to be able to load the org.GNOME.Accessibility.AtkWrapper class.

Now, it looks working here. At least, nothing is existing with
classnotfound exception. However, me being rather ignoramus concerning
Java, I would not mind someone in the know to review it for obvious
mortal sins against Java.

Cheers

Fridrich

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

Re: java-atk-wrapper accessibility and openjdk9

Fridrich Strba
The previous solution worked, but only after some little java program
was launched. So I assume that the classloader was reading the property
too early and this worked only because of some caching.

That is why I came with this other patch that looks working for me.
Although, there is still some caching going on, because if I change the
accessibility.properties, the change is not take in account in the
current shell, but if I change shell, yes. Nevertheless, this one loads
the org.GNOME.Accessibility.AtkWrapper and even when java is first
launched by an applet it works.

Cheers

Fridrich

On 17/10/17 14:33, Fridrich Strba wrote:

> Hello, good people,
>
> Since the OpenJDK 9 removed the extension system, I was -- on and off --
> thinking how to fix the java-atk-wrapper based accessibility. I wanted
> to achieve something similar to what many distro packagers do for all
> versions up to 8. Having a package of symlinks and
> accessibility.properties file that tells the Java ATK which assistive
> technologies to use. I wanted something that would be activated when the
> package is installed and would have the normal behaviour when not.
>
> I came with the attached patch.
>
> Basically, it is enough to put into the accessibility.properties file a
> property "assistive_technologies_classpath" pointing to the
> java-atk-wrapper.jar and it will be added to the system property
> java.class.path. It looks like it is done enough early for the
> classloader to be able to load the org.GNOME.Accessibility.AtkWrapper class.
>
> Now, it looks working here. At least, nothing is existing with
> classnotfound exception. However, me being rather ignoramus concerning
> Java, I would not mind someone in the know to review it for obvious
> mortal sins against Java.
>
> Cheers
>
> Fridrich
>


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

Re: java-atk-wrapper accessibility and openjdk9

Fridrich Strba
So, this is the third iteration of my patch and it is patching
completely different place. This patch assures that the
java-atk-wrapper.jar is considered in the time when the assistive
technologies are loaded. We add this element to the class path before
the internal class loaders are instantiated.

We are checking whether the file that was specified in the
assistive_technologies.classpath 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, I am not sure whether I will be officially and publicly stoned if I
propose this upstream. Therefore, I would not mind if someone had a look
and blew me before I ridicule myself even more.

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: java-atk-wrapper accessibility and openjdk9

Jiri Vanek
On 10/24/2017 05:27 PM, Fridrich Strba wrote:

> So, this is the third iteration of my patch and it is patching
> completely different place. This patch assures that the
> java-atk-wrapper.jar is considered in the time when the assistive
> technologies are loaded. We add this element to the class path before
> the internal class loaders are instantiated.
>
> We are checking whether the file that was specified in the
> assistive_technologies.classpath 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, I am not sure whether I will be officially and publicly stoned if I
> propose this upstream. Therefore, I would not mind if someone had a look
> and blew me before I ridicule myself even more.
>

Hi!

I'm an target, and really enjoying this "thread", audience.
You write yout version more quickly then I'm able to answer:) Thank yo for IRC chats.

TBH I really like this effort. The accessibility toolkit as is now, is close to be useless.
This thread is changing it to be at lease used.

Instead of voting for public stoning, i would vote to usptream this. At least post to awt thread. At
least we will see if it canbe harmfull in some way. There are much ore terribel pits in JDK then you
nicehack :). This patch is doing what it is supposed to do, and looks good. Fingers crossed


Thank you very much for this effort!
   J.


--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
[hidden email]    M: +420775390109
Reply | Threaded
Open this post in threaded view
|

Re: java-atk-wrapper accessibility and openjdk9

Fridrich Strba
In reply to this post by Fridrich Strba
OK, I sent it to awt-dev:
http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013251.html

As usual, I was a bit more verbose then it was decent, but ... even my
wife is putting up with it, so it is not mortal.

Let us see what will come up. In the meantime, I would not mind if a
user used to the assistive technologies could try how this fares from
her point of view.

Cheers

Fridrich

On 24/10/17 17:27, Fridrich Strba wrote:

> So, this is the third iteration of my patch and it is patching
> completely different place. This patch assures that the
> java-atk-wrapper.jar is considered in the time when the assistive
> technologies are loaded. We add this element to the class path before
> the internal class loaders are instantiated.
>
> We are checking whether the file that was specified in the
> assistive_technologies.classpath 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, I am not sure whether I will be officially and publicly stoned if I
> propose this upstream. Therefore, I would not mind if someone had a look
> and blew me before I ridicule myself even more.
>
> Cheers
>
> Fridrich
>


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

Re: java-atk-wrapper accessibility and openjdk9

Fridrich Strba
Good people,

So, there are some news from the awt-dev
http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013253.html
and http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013254.html

It looks like the java-atk-wrapper has to implement the
https://docs.oracle.com/javase/9/docs/api/javax/accessibility/AccessibilityProvider.html

Which, in my understanding means implementing two methods: getName and
activate. Not sure whether creating a new class that implements those
two methods and where the activate method loads the AtkWrapper class
should be enough.

They provide basically two ways to load this then. One is to modify the
jdk by adding to <javahome>/lib/modules the java-atk-wrapper as a
module. Which would mean for packaging purposes either distributing it
always (with all the chicken-egg problem that comes with it), or have
two different JDKs built (one with and one without j-a-w).

Nevertheless, the second e-mail gives an opening to having this jar
simply on class path. Although they say that patching internal class
loaders is not a good idea (and I understand perfectly where they come
from), the patch still achieves what we need and personally, with my
little reptilian brain, don't see how I could introduce there a security
hole with those lines. So, I think that implementing the
javax.accessibility.AccessibilityProvider in j-a-w could solve our
problem and have still the advantage of being a drop-and-use solution
that does not need to modify the whole jdk.

Some thoughts?

Fridrich

On 25/10/17 14:59, Fridrich Strba wrote:

> OK, I sent it to awt-dev:
> http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013251.html
>
> As usual, I was a bit more verbose then it was decent, but ... even my
> wife is putting up with it, so it is not mortal.
>
> Let us see what will come up. In the meantime, I would not mind if a
> user used to the assistive technologies could try how this fares from
> her point of view.
>
> Cheers
>
> Fridrich
>
> On 24/10/17 17:27, Fridrich Strba wrote:
>> So, this is the third iteration of my patch and it is patching
>> completely different place. This patch assures that the
>> java-atk-wrapper.jar is considered in the time when the assistive
>> technologies are loaded. We add this element to the class path before
>> the internal class loaders are instantiated.
>>
>> We are checking whether the file that was specified in the
>> assistive_technologies.classpath 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, I am not sure whether I will be officially and publicly stoned if I
>> propose this upstream. Therefore, I would not mind if someone had a look
>> and blew me before I ridicule myself even more.
>>
>> Cheers
>>
>> Fridrich
>>
>
>


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

Re: java-atk-wrapper accessibility and openjdk9

Fridrich Strba
Good people,

On 26/10/17 08:40, Fridrich Strba wrote:
> It looks like the java-atk-wrapper has to implement the
> https://docs.oracle.com/javase/9/docs/api/javax/accessibility/AccessibilityProvider.html
>
> Which, in my understanding means implementing two methods: getName and
> activate. Not sure whether creating a new class that implements those
> two methods and where the activate method loads the AtkWrapper class
> should be enough.

Actually reading the code in java.awt.Toolkit, I realize that
java-atk-wrapper as it is now can work. For any class that is declared
as assistive_technologies and does not implement the
AccessibilityProvider, the java.awt.Toolkit has a static method
fallbackToLoadClassForAT which loads happily the AtkWrapper with the
class name from our java-atk-wrapper.jar.

So, this solution, although maybe not as elegant as that, could work.

Cheers

Fridrich

P.S.: It is always possible to implement the AccessibilityProvider by
dropping the attached file to the wrapper/org/GNOME/Accessibility/
directory and also craft inside the JAR file a
META-INF/services/javax.accessibility.AccessibilityProvider with content
"org.GNOME
.Accessibility.AtkWrapper"

AtkProvider.java (1K) Download Attachment
signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: java-atk-wrapper accessibility and openjdk9

Fridrich Strba
OK, with the attached patch, the java-atk-wrapper is loaded using the
javax.accessibility.AccessibilityProvider service.

I also modified the required java version in the configure.ac, since
source level 6 cannot be use because of "Hash<>" in the code.

It would be still good condition the compilation of the AtkProvider.java
to the fact one is compiling with java9, since the extended class was
introduced in java 9.

As I said, with this patch the provider is activated with
loadAssistiveTechnologies without having to go to the
fallbackToLoadClassForAT. But, at the end of the day, both bring us to
the same result, the java-atk-wrapper being loaded.

I gave a little thought to the approach of making this a module and
include it in the jdk, but that would mean basically to have distributed
also the libjava-atk-wrapper.so, which would mean the whole package
depending on the Gnome atk stack including gdk and glib. Not something
that would one really want, IMHO.

Cheers

F.

On 26/10/17 09:40, Fridrich Strba wrote:

> Good people,
>
> On 26/10/17 08:40, Fridrich Strba wrote:
>> It looks like the java-atk-wrapper has to implement the
>> https://docs.oracle.com/javase/9/docs/api/javax/accessibility/AccessibilityProvider.html
>>
>> Which, in my understanding means implementing two methods: getName and
>> activate. Not sure whether creating a new class that implements those
>> two methods and where the activate method loads the AtkWrapper class
>> should be enough.
>
> Actually reading the code in java.awt.Toolkit, I realize that
> java-atk-wrapper as it is now can work. For any class that is declared
> as assistive_technologies and does not implement the
> AccessibilityProvider, the java.awt.Toolkit has a static method
> fallbackToLoadClassForAT which loads happily the AtkWrapper with the
> class name from our java-atk-wrapper.jar.
>
> So, this solution, although maybe not as elegant as that, could work.
>
> Cheers
>
> Fridrich
>
> P.S.: It is always possible to implement the AccessibilityProvider by
> dropping the attached file to the wrapper/org/GNOME/Accessibility/
> directory and also craft inside the JAR file a
> META-INF/services/javax.accessibility.AccessibilityProvider with content
> "org.GNOME
> .Accessibility.AtkWrapper"
>


jaw-java9.patch (4K) Download Attachment
signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: java-atk-wrapper accessibility and openjdk9

Fridrich Strba
So, I gave a good thought to making the java-atk-wrapper a modular jar
and I came with a serie of patches that I submitted to GNOME bugzilla.
This one contains all patches that fix some issues I had with it, but
that will not force us to build it with source/target 9:

https://bugzilla.gnome.org/show_bug.cgi?id=789956

This bug has the two patches that (1) make the j-a-w implement the
javax.accessibility.AccessibilityProvider interface that is new in jdk9
and (2) build j-a-w as a modular jar:

https://bugzilla.gnome.org/show_bug.cgi?id=789959

These two patches modify the java-atk-wrapper so much that I don't think
putting them into the source tree is useful at this point. I submitted
them into bugzilla for the reference of future generations who would
have the same itch to scratch.

I attached minimal versions of patches that change only the necessary
parts so that I can build java-atk-wrapper inside the rpm build and link
the atk.wrapper (as I named it) module into the jdk. The java code is
then always part of the jdk, but the -accessibility package adds the
native library into JAVA_HOME/lib/ and the accessibility.properties file
into JAVA_HOME/conf. Without the accessibility.properties file, the
AtkProvider is not even trying to load. This is still then corresponding
to the result I wanted so that the accessibility doesn't need to be
configured by user, just the -accessibility package installed.

Cheers

Fridrich

P.S.: The part of my rpm spec file that builds and merges the
atk.wrapper module is:

# Build the accessibility plugin
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



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