Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO
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 : > > 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
Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO
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 ...
Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO
Thank you Rony for the Java deep dive. 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
Java, OOo, ... (Re: [discussion] future embedded DB in AOO
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
