Accessibility provider classpath
Samuel Thibault
samuel.thibault at ens-lyon.org
Mon Aug 26 21:10:58 UTC 2024
Hello,
Vladimir Petko, le mar. 27 août 2024 08:44:12 +1200, a ecrit:
> A recap of the problem i am trying to solve below:
>
> Java accessibility requires accessibility provider classes to be
> present in the application classpath.
>
> In Java 8 accessibility provider jar was added to the "lib/ext"
> directory and the accessibility provider was added to the boot
> classpath. Some Linux distributions carried a patch that modified the
> boot classpath for Java 11 and up to include a predefined
> accessibility provider.
>
> Updating the boot classpath was a security risk and did not allow for
> alternative implementations of the accessibility provider that are
> configurable system-wide.
>
> Since Java runtime attempts to load accessibility using the
> application's classpath, a user has to modify each application's
> classpath to enable accessibility. This is a bad user experience.
> Sometimes it is not possible, e.g. the application files are
> immutable.
>
> Accessibility provider classpath can be specified in a new additional
> property in accessibility.properties. The older versions of JDK will
> ignore it and the change will not break an existing functionality.
So distributions would set in accessibility.properties's
assistive_technologies.classpath the classpath to be used?
Yes, that would be a nice way.
I'm eager to see if openjdk eventually understands that this is needed
(last time I tried to raise the issue, Oracle wasn't even realizing that
accessibility was completely broken).
> I have prepared a prototype[1]
Thanks for this!
> and was wondering if it would be ok to raise an enhancement issue and
> implement it.
FWIW, I'm all for it!
Samuel
> [1] https://github.com/openjdk/jdk/compare/master...vpa1977:jdk:accessibility_proto
>
> On Thu, Sep 21, 2023 at 10:21 AM Samuel Thibault
> <samuel.thibault at ens-lyon.org> wrote:
> >
> > Vladimir Petko, le jeu. 21 sept. 2023 10:11:38 +1200, a ecrit:
> > > Samuel, please correct me if I'm wrong. The requirement is for the
> > > per-user (or system-wide) enablement of accessibility. The
> > > per-application setup is a bad user experience, and it would be nice
> > > to have a single point - properties file - that enables it.
> >
> > Yes, that's it.
> >
> > It is meaningless to enable accessibility only for some applicatins:
> > either the user needs it for all applications, or they don't need it at
> > all.
> >
> > Samuel
> >
> > > Java 8 achieves this by putting the accessibility provider jar in the
> > > 'ext' directory. Java 11 and up requires including an accessibility
> > > provider in the modules files.
> > >
> > > Any updates and fixes to the accessibility provider will require new
> > > releases of the openjdk package in Debian and Ubuntu. Adding
> > > accessibility providers to the build dependencies of the openjdk
> > > package also creates a circular build dependency that might introduce
> > > issues requiring careful synchronization between releases.
> > >
> > > I propose to add a new property 'java.accessibility.module_path'. The
> > > property will contain the list of locations of accessibility modules.
> > > Toolkit will construct the classloader using this path and the system
> > > class loader as a parent. Older releases will ignore this property.
> > >
> > > This feature will allow installation of the accessibility provider
> > > separate from the openjdk package and will satisfy the requirement of
> > > per-user and system-wide enablement of the accessibility provider.
> > >
> > > Best Regards,
> > > Vladimir.
> > >
> > > On Thu, Sep 21, 2023 at 9:48 AM Philip Race <philip.race at oracle.com> wrote:
> > > >
> > > > Can you explain your need for this (a lot) better ?
> > > >
> > > > The location and loading is specified to be done by
> > > > java.util.ServiceLoader.
> > > > Whilst this might be possible by some enhanced syntax, which if present
> > > > invokes ServiceLoader specifying a ClassLoader for this jar file, it
> > > > would clearly be new API and only for future releases.
> > > > NB it would also be fiddly to implement as the value of the property is
> > > > a list of class names and
> > > > you can't add jar names to that without breaking older JDKs and
> > > > so you'd need some way to match new lines referencing the JAR file for
> > > > each class ..
> > > >
> > > > And likely we'd want to have new APIs like this - if they make sense - to
> > > > be focused on a module, not a jar, but building a runtime image from
> > > > modules using jlink is a normal thing to do, so I'm not sure what such
> > > > an API would look like and seems to be not what you want.
> > > >
> > > > I also don't understand the use case / problem.
> > > > Whatever launches your application can set
> > > > -Djavax.accessibility.assistive_technologies=<..>
> > > > and set the -cp to include your jar and you don't need to do anything
> > > > to the runtime image.
> > > >
> > > > -phil
> > > >
> > > > On 9/20/23 1:33 PM, Vladimir Petko wrote:
> > > > > Hi,
> > > > >
> > > > > Java accessibility.properties (.accessibility.properties) allows
> > > > > setting the class name of the accessibility provider but not the jar
> > > > > file containing it.
> > > > >
> > > > > Was there any consideration that prevents this feature from being
> > > > > implemented, such as security?
> > > > >
> > > > > It would be nice to have it implemented to allow system-wide/per-user
> > > > > configuration of the accessibility provider without rebuilding the
> > > > > runtime image.
> > > > >
> > > > > If this is something acceptable, I am happy to create an enhancement
> > > > > issue and work on it.
> > > > >
> > > > > Best Regards,
> > > > > Vladimir.
> > > >
> > >
> >
> > --
> > Samuel
> > ---
> > Pour une évaluation indépendante, transparente et rigoureuse !
> > Je soutiens la Commission d'Évaluation de l'Inria.
>
--
Samuel
RR> Ce que je cherche à démontrer, c'est qu'il est injuste de faire
RR> l'amalgame entre du bulk mail et du courrier non-solicité très ciblé
un suppositoire non reclamé, meme tres bien ciblé, reste un suppositoire.
-+-OS in : Guide du Neuneu d'Usenet - Plein le cul de la pub à neuneu -+-
More information about the client-libs-dev
mailing list