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/
