You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Rony G. Flatscher (Apache)" <ro...@apache.org> on 2020/12/08 18:11:11 UTC
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 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/
Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO
Posted by Rony G Flatscher <ro...@wu.ac.at>.
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 <ma...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO
Posted by Matthias Seidel <ma...@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/
>>
>>
>>
>>
Re: Java, OOo, ... (Re: [discussion] future embedded DB in AOO
Posted by Peter Kovacs <pe...@apache.org>.
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
> 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/
>
>
>
>
--
This is the Way! http://www.apache.org/theapacheway/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org