Re: Question on Java JDK build environments impacting JRE use

Noel,

You have continued to say that simply changing the byte code does nothing. 

Even if we accept that, the issue remains that there are functional
differences between the current feature set represented by J2SE 5.0 targeted
bytecode and the current feature set that JDK SE 7  is configured to produce
and JRE 7 framework is designed to consume. 

This is a problem for us because a prominent functional change introduced by
Oracle at the JRE 1.7u6 build was inclusion of the Java AccessBridge code
into all builds of the JRE for Windows--it can be toggled on or off, but
Oracle has not published the API for the Java Access Bridge and the source
code was removed from OpenJDK.

In other words, we are working blind against the java access bridge's
interface to Java Accessibility API, and still blindly continue to build
J2SE 5.0 target bytecode.   And as a result  Accessibility  and AT tool
support on Windows OS builds are broken!  

There is no Accessibily for Windows OS users when JRE 1.7 is in use and
workarounds are becoming increasingly hard to maintain.  All the more
insidious because Oracle's automated Java  update mechanism for Windows OS
replaces functional JREs with new non-functional JREs and more
dissatisfaction with LibreOffice quality results.

For a project that has moved Python3.3  integration to the forefront, it
seems a little misguided to allow the JRE framework to languish with code
features designed at the J2SE 1.4.2 branch.

If some minor refactoring to generate viable Java SE 7 bytecode results in
regained Accessibility and AT tools support with Java SE 7 that would be
wonderful.  Might be that simple, or might not,  but it still needs to be
fixed.

Stuart



--
View this message in context: 
http://nabble.documentfoundation.org/Question-on-Java-JDK-build-environments-impacting-JRE-use-tp4062592p4062806.html
Sent from the Dev mailing list archive at Nabble.com.