Accessibility provider classpath

Samuel Thibault samuel.thibault at ens-lyon.org
Wed Sep 20 22:21:04 UTC 2023


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.


More information about the client-libs-dev mailing list