Thank you as well, also for the link which I was not aware of! 😊 —-rony
Rony G. Flatscher (mobil/e) > Am 10.12.2020 um 12:49 schrieb Matthias Seidel <matthias.sei...@hamburg.de>: > > Hi all, > >> Am 10.12.20 um 01:59 schrieb Peter Kovacs: >> Thank you Rony for the Java deep dive. > > +1 > > And BTW: > > https://www.youtube.com/watch?v=p4DeOilMOQA > > Regards, > > Matthias > >> >>> On 08.12.20 19:11, Rony G. Flatscher (Apache) wrote: >>> Hmm, just some thoughts and pointers that may be helpful in the >>> context of the current Java and >>> possibly HSQL discussions. >>> >>> Ad Java and OpenOffice >>> >>> IMHO Java has been fulfilling Sun's original promise "write >>> once, run everywhere" in a very >>> impressive way for decades by now! When Sun (being the inventor >>> of Java) bought Star Division >>> to acquire StarOffice and making the source also available via >>> openoffice.org, Sun also had the >>> Java interfaces put into the office suite, such that Java >>> programmers would be able to interface >>> with OOo (using "OOo" to also mean AOO and the LO-fork) via UNO >>> to this very day, and also >>> enabling Java to become an additional programming language to >>> C++ to create OOo packages. This >>> has been some achievement and to me has been impressive to this >>> very day! >>> >>> Java AOO components and Java applications interacting with AOO >>> have been working for almost >>> decades without a need of change! (Also such applications would >>> be deployable on different >>> operating systems without a need to rewrite and recompile them!) >>> >>> Discussing removing Java dependencies given this history and >>> integration makes me a little bit >>> nervous if looking at some of the arguments, which may go back >>> to misconceptions, hear-say and >>> possibly wrong information published about Java (like Oracle's >>> change in its license would make >>> it impossible for software XXX to continue to use it ... which >>> simply is not the case). >>> >>> The scripting interface to OOo is written in Java. Therefore it >>> has become possible to use the >>> Java implemented scripting languages JavaScript and BeanShell to >>> create OOo macros, besides OOo >>> Basic and Python. In addition - as others have done also - I >>> authored a little package that uses >>> the OOo scripting interface in order to make another scripting >>> language (ooRexx [1]) available >>> as an OOo macro language (one package creates a bidirectional >>> bridge between ooRexx and Java >>> [2], the other package camouflages UNO as ooRexx and exploits >>> the UNO reflection mechanism to >>> make it easy on programmers to interface with OOo [3]), so this >>> is one reason, why being a >>> little bit nervous about a possible wrong assessment of Java... >>> >>> Ad Java Distributions >>> >>> It seems that many people think that Java is only available in a >>> proprietary form from Oracle >>> [4], which changed its license terms for its Java 1.8/8 and up, >>> around the time when modular >>> Java (Java 9) got released. Oracle is regarded to be the owner >>> of Java and therefore people tend >>> to think that there is no open-source, free alternative >>> available, which is not correct. >>> >>> Enter "OpenJDK" [5] the open-source version of Java: this allows >>> you to use Java for free (it is >>> GPL with the CLASSPATH exception license such that your code >>> using it does not fall under GPL >>> automatically). With the modular versions of Java, starting with >>> Java 9, one is even able to >>> create one own's Java (runtime environment, JRE) by combining >>> the Java modules one wishes to >>> deploy[6]. (This would even open up the opportunity for OOo to >>> create and distribute its own >>> tailored JRE, should such a need arise.) >>> >>> If you do not feel inclined to create your own JRE (Java >>> runtime-environment) then you can >>> download Java=OpenJDK JRE for your particular platform from e.g. >>> AdoptOpenJDK [7], Liberica [8] >>> or Zulu [9] to name a few. >>> >>> So Java is available in an open-source and free form with the >>> term OpenJDK (open Java >>> development kit) [5]. >>> >>> One tidbit in this "license" context: programmers who wish to >>> contribute to Java/OpenJDK must >>> sign an "OCA" (Oracle contributer agreement [15]) giving more or >>> less all rights on the >>> contributed software to Oracle which then makes the software >>> available to the OpenJDK with GPL >>> and the CLASSPATH exception. Something that Sun had done with >>> software contributed to OOo. This >>> BTW allowed later Oracle (after buying Sun and acquiring all of >>> Sun's software rights) to >>> contribute the OOo source code to the Apache software >>> foundation, making it in the end possible >>> to create and release AOO under the Apache license! (BTW, one >>> would be able to release one >>> own's, contributed code with additional, different licenses. >>> Something that would also be >>> possible for e.g. LO-contributors, but many are not aware of >>> this it seems.) >>> >>> Ad Java 1.8/8 Versus Java 9 and Later ... >>> >>> Java 9 got introduced in the fall of 2017 [10]. There are a few >>> notable changes: >>> >>> * one being that Java has been finally modularized: internal >>> and reflective code now is >>> access-based (using the package java.lang.invoke), such that >>> setAccessible as used in the >>> prior versions via the java.lang.reflect package in order to >>> invoke reflectively will not be >>> allowed anymore. In the transition phase this may cause >>> many, many problems with code that >>> was created prior to Java 9, such that for some time the >>> modularized versions of Java will >>> tolerate access via java.lang.reflect as in the past (and >>> there are even provisions in place >>> to have command-line arguments to extend these permissions >>> for a longer period with newer >>> versions of modularized Java). (Where java.lang.reflect >>> would be usable to invoke a method >>> in the otherwise inaccessilbe sun-package, java.lang.invoke >>> will not allow that if the >>> module is not exported, rather one needs to go up the >>> inheritance tree to find a class in an >>> accessible/exported module and invoke the method via that >>> class' method object), >>> >>> * one can create one own's Java runtime environment (JRE) from >>> the Java modules [6]; >>> Java/OpenJDK 11 for instance does not contain the four >>> JavaFX modules by default (a >>> separate, active project, OpenJFX [16]) anymore; >>> Java/OpenJDK 15 removes Nashorn >>> (JavaScript), however at the end of November a proper >>> Nashorn (JavaScript) module was made >>> available that can be mixed into one own's modular JRE >>> (again look at the sample in [6] to >>> save yourself some research time) of Java 15 or later, >>> >>> * the release cycle of Java/OpenJDK had been changed to six >>> (!) months: hence there have been >>> two major releases of Java/OpenJDK per year since then, the >>> latest one being Java/OpenJDK 15 >>> as of September 2020. One purpose supposedly was to make it >>> possible to add new features to >>> the Java/OpenJDK language quicker than in the past. The LTS >>> (long-term support) versions are >>> then roughly comparable to the classic release cycles of >>> Java/OpenJDK, cf. [10]. >>> >>> If you look at the Java/OpenJDK versions [10] you will see >>> "LTS", where Java 8 will be serviced >>> until 2030 (!) and the modular LTS version Java/OpenJDK 11 will >>> be serviced until September >>> 2026, another six years from now. >>> >>> Ad HSQL >>> >>> It seems that the rather old version of AOO's HSQL may have been >>> caused by sticking to older >>> versions of Java. HSQL [11] states that the HSQL version 2.3.8 >>> is based on Java 1.6/6, and its >>> latest HSQL version 2.5.1 (as of June 2020) is based on >>> Java/OpenJDK 1.8/8. No idea whether >>> 2.3.8 or 2.5.1 break with the older APIs that the current AOO >>> employs. (There is an interesting >>> comparison of the properties of HSQL and H2 [12] at [13]. For >>> completeness in the context of the >>> discussions, the homepage of Apache Derby: [14].) >>> >>> With this information, hopefully, Java remains as a first citizen in >>> AOO! >>> >>> Ceterum censeo, Java should remain as a first citizen in AOO! >>> :) >>> >>> HTH, >>> >>> ---rony >>> >>> >>> [1] ooRexx (implemented in C++): >>> <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/> >>> >>> [2] BSF4ooRexx (Java bridge a mixture of C++, Java and ooRexx): >>> <https://sourceforge.net/projects/bsf4oorexx/files/beta/20200928/> >>> >>> [3] "Scripting Apache Office", slides, ApacheCon Europe 2012, Germany: >>> <AutoJava-BSF4ooRexx-04-OOo-ACE12.pdf >, UNO programming, programming >>> swriter, scalc, sdraw, >>> simpress, URE (UNO runtime environment) >>> >>> [4] Oracle's Java: <https://java.com/> >>> >>> [5] OpenJDK: <https://openjdk.java.net/> >>> >>> [6] "Setup Environment for Java/OpenJDK (2020-05-29)", slides, WU >>> Vienna/Austria: >>> <http://wi.wu.ac.at/rgf/wu/lehre/autojava/material/foils/AutoJava-BSF4ooRexx-08-Environment.pdf >>>> >>> >>> [7] "AdoptOpenJDK" OpenJDK/Java: <https://adoptOpenJDK.net>; this >>> version even allows you to even >>> pick the JVM to run Java >>> >>> [8] "Liberica" OpenJDK/Java: <https://bell-sw.com/>, look for "full >>> Liberica", if you want the >>> JavaFX modules to be available >>> >>> [9] "Zulu" OpenJDK/Java: <https://www.azul.com/downloads/>, look for >>> "JDK FX", if you want the >>> JavaFX modules to be available >>> >>> [10] "Java version history", Wikipedia: >>> <https://en.wikipedia.org/wiki/Java_version_history >>> >>> [11] "HyperSQL", Homepage: <http://hsqldb.org/> >>> >>> [12] "H2 Database Engine", Homepage: <https://www.h2database.com/> >>> >>> [13] "System Properties Comparison H2 vs. HyperSQL", a current article: >>> <https://db-engines.com/en/system/H2%3BHyperSQL> >>> >>> [14] "Apache Derby", homepage: <https://db.apache.org/derby/> >>> >>> [15] "Oracle's Contributor Agreement (OCA)": >>> <https://www.oracle.com/technical-resources/oracle-contributor-agreement.html> >>> >>> >>> [16] "OpenJFX", homepage: <https://openjfx.io/ >>> >>> >>> >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
