Re: Question on Java JDK build environments impacting JRE use
On 2013-06-23 17:24, V Stuart Foote wrote: Thanks! The zip'd packaging is fine for testing, have grabbed a copy. Will run with it and a JRE 1.7u25 and JAB 2.0.3, but noticed for starters that the build target for the Java bytecode is still set to major/minor 49.0, or J2SE 5. Is that a javac compatibility mode setting of some sort? Useful none the less, but might not see interesting changes until able to assess java compiled to Java 7 bytecode, i.e. major/minor 51.0. Just hope there is not a lot of code refactoring to get to that point. Changing the version number of the Java bytecode will have absolutely no impact on your problem because the Java-VM happily loads bytecode versions all the way back to Java1.0 i.e. it has pretty much perfect backwards compatibility in that respect. You are more likely to be seeing some kind of subtle change in timing, or a small but significant change in how some part of the Java runtime behaves. You could try doing a manual binary search through the Java runtime versions, that might help narrow it down. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question on Java JDK build environments impacting JRE use
On 2013-06-23 19:25, V Stuart Foote wrote: Issue of bytecode target interaction with JRE becomes more troubling if you consider that the default Java JRE update settings on Windows systems replace all JRE 6 installations with current JRE 7 builds. In other words the percentage of total LibreOffice ussers with JRE 1.5 or JRE 1.6 installations even installed is rapidly shrinking. There is no bytecode interaction problem. You are seeing some kind of bug brought on by a newer version of Java interacting slightly differently with LO. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question on Java JDK build environments impacting JRE use
David, David Ostrovsky-3 wrote But anyway i can conduct a new and shiny 51 byte code version of LO if you would like to try it and see if we have any improvements with JAB with it? I would still very much like to explore this further if you are able to generate viable Java 1.7 bytecode of master without having to refactor the entire project to meet stricter code requirements of Java SE 7. In any case, I hope you've convinced yourself that there really is an issue with the JRE 1.7u25 JAB v2.0.3 bridge of UNO Accessability API -- Java Accessibility API serviced by JRE 7 on Windows OS and tht fdo#58995 remains a valid accessibility issue for LibreOffice. Let me know if you still have doubts. Also, apologies for that rather confusing set of postings to the fdo#58995 bug. I really should just start editing outside BZ and then paste into the dialog. Setting up just a 32-bit JRE and the associated JavaFerret-32.exe (from the Java SE 6 Java Access Bridge package) functions as a Graphical accessibility explorer. It is comparable in function to tools provided in Python based *Accerciser* for GNOME AT-SPI, or the *AccProbe* Eclipse Rich-Client Product for evaluating IAccessible2 on Windows, or even Microsoft's Inspect.exe for UIAutomation and MAA accessibility events and roles. Along with JavaFerret-32, Oracle (via Sun) also provides the JavaMonkey-32 which compliments javaferret with a GUI tree representation of a documents accessible objects. While JavaFerret will show the attributes of any single accessible object--the tree representation of JavaMonkey shows hierarchical relationships of parent and child so they complement each other but JavaFerret is really the tool of choice when assessing how well AT tools can be interfaced. They've not repackaged them as JRE 7 utilities, but the packaging in JAB v2.0.2 build still functions well enough. In a perfect world attributes (annotations hard coded into the source) for both the Ferret and the Monkey representations would be fully populated--as Oracle has done with the SwingSet2.jar demo. Reality is, we are doing well if we have correct AccessibleRole assigned along with parent and child relationships. At some point we will gain access to the Apache OpenOffice work being done on their IA2 port from IBM Symphony and have the start of an UAA -- IAccessible2 bridge for Windows. That will reduce dependence on the Java Accessibility API and JRE using the Java AccessibilityBridge, but as Oracle support for J2SE 1.5 and Java SE 6 is retracting--we have to do something to improve function of Java 7 JREs for Windows based users. Stuart -- View this message in context: http://nabble.documentfoundation.org/Question-on-Java-JDK-build-environments-impacting-JRE-use-tp4062592p4062800.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question on Java JDK build environments impacting JRE use
Hi I am quite happy for us for produce Java7 bytecode, if producing Java7 bytecode will actually make something work better. But so far I have seen no signs of that. And I'm speaking here, not as some random hacker, but as a person with 10+ years experience of writing 1Mloc+ Java applications, who has had the mispleasure of actually writing bytecode by hand. 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. There is no languishing going on here, simply good software engineering. Changing the constants in the bytecode header has no effect at runtime UNLESS YOU ARE ALSO USING THE NEW BYTECODE FEATURES. Which we are not. There is nothing in our current codebase which could make use of newer bytecode features. As soon as such a thing appears, I will be very happy to lend my support to upgrading our bytecode version. Regards, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question on Java JDK build environments impacting JRE use
On Sat Jun 22 Stuart Foote wrote: [...] Could anyone spin up a TB to build Windows (possibly OSX) master using JDK 7 [...] Any takers? just uploaded a very recent LO debug build (from the last Hackathon, June 16) with that endless loop fix applied [1]: http://ostrovsky.org/libo/LibreOfficeDev_4.2.0.0.alpha0_Win_x86_archive.zip It is built on Windows 7, MSVC 2010, JDK 7, debug mode. If you rather prefer msi package, let me know. [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=865b5caf6e2256e06f46a39a86d67f03408718a9 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question on Java JDK build environments impacting JRE use
David, Thanks! The zip'd packaging is fine for testing, have grabbed a copy. Will run with it and a JRE 1.7u25 and JAB 2.0.3, but noticed for starters that the build target for the Java bytecode is still set to major/minor 49.0, or J2SE 5. Is that a javac compatibility mode setting of some sort? Useful none the less, but might not see interesting changes until able to assess java compiled to Java 7 bytecode, i.e. major/minor 51.0. Just hope there is not a lot of code refactoring to get to that point. Stuart -- View this message in context: http://nabble.documentfoundation.org/Question-on-Java-JDK-build-environments-impacting-JRE-use-tp4062592p4062715.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question on Java JDK build environments impacting JRE use
David, Yes! I will happily work with your JDK 7 based build with Java 7 bytecode to see if that restores the JAB function Oracle clobbered when they moved Java Access Bridge into the base JRE at 1.7u6. Thanks for the history... Can't fault Tor's work on fixing the compiler java_target_version to 1.5 across all build platforms. But the comments made in rejecting your https://gerrit.libreoffice.org/#/c/2884/ seem a little short sighted because at that point we'd already demonstrated that the JRE 7 built in JAB was NOT functioning correctly for providing UAA based Assistive Technology tools to Windows OS desktops and filed fdo#58995. And any of the thousands of AT dependent LibreOffice users on Windows can attest that UAA -- JAB AT is impacted because we've had to have folks jump through hoops to obtain a functional AT (see https://wiki.documentfoundation.org/Faq/Java or https://wiki.documentfoundation.org/Accessibility ). Issue of bytecode target interaction with JRE becomes more troubling if you consider that the default Java JRE update settings on Windows systems replace all JRE 6 installations with current JRE 7 builds. In other words the percentage of total LibreOffice ussers with JRE 1.5 or JRE 1.6 installations even installed is rapidly shrinking. Stuart -- View this message in context: http://nabble.documentfoundation.org/Question-on-Java-JDK-build-environments-impacting-JRE-use-tp4062592p4062733.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question on Java JDK build environments impacting JRE use
Le 22/06/2013 18:45, V Stuart Foote a écrit : Hi Stuart, Could anyone spin up a TB to build Windows (possibly OSX) master using JDK 7, or possibly even Open JDK 8 beta (which has been marked M7 Feature Complete as of 2013/06/13 ) and build Libreoffice with J2SE 7 classes? And, if not too complicated to put up a TB with that capability, it would be very helpful to test native Java 1.7 bytecode to determine if that resolves some of the JAB issues of fdo#58995. And think it would also be interesting to see if that helps the Report Builder and HSQLDB issues. And maybe some positive impact on the OSX side as well. FWIW, there is already a report in BZ about Java 1.7 not being recognized in OSX 10.8. Stock OSX 10.8 apparently doesn't come with a JVM anymore out of the box, and the only available maintained JVM for OSX is 1.7, which in essence poses a problem for any and all functionality within LO that makes Java calls. I don't know how the new OSX buildbot deals with this or what version of OSX it is running. On upgraded OSX machines, i.e. ones that have gone through the 10.6, 10.7 to 10.8 cycle,we still have the maintained JVM provided by Apple (1.6_xx). These are just my observations, perhaps others can shed more light. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question on Java JDK build environments impacting JRE use
On Sun, Jun 23, 2013 at 08:10:42PM +0200, David Ostrovsky wrote: On Sun Jun 23 08:24:32 PDT 2013 Stuart Foote wrote: Will run with it and a JRE 1.7u25 and JAB 2.0.3, but noticed for starters that the build target for the Java bytecode is still set to major/minor 49.0, or J2SE 5. Is that a javac compatibility mode setting of some sort? Especially friendly is that comment: ... keeping you from unconditionally setting -source 1.6 -target 1.6 in your private tree until such time as your work is ready to make it's way upstream ... because that's the way and the spirit how open source projects work: Don't share anything with anyone until you are actually done! You can share code that is not ready for the official tree by pushing it to a feature/foo branch in git. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
