New JAVA for openHAB3 #629
Labels
Milestone
Comments
EliasGabrielsson
added
base system
EliasGabrielsson
changed the title
mstormi
changed the title
|
There have been a number of proposals, issues and pieces of information related to what Java to use in the future such as #805, #766, #729, #723, #714, a number of forum posts such as https://community.openhab.org/t/running-openhab-2-on-openjdk/21443/8?u=benjy and more. Please move all activities and discussions to https://github.com/orgs/openhab/teams/refocus-ian/discussions/6 to be the central place for discussing the way forward w.r.t. Java provider. |
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 28, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms so as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 28, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms so as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 29, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 29, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 29, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 30, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 30, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 30, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 30, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 30, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
Apr 30, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 3, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 3, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 3, 2020
Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
mstormi
pushed a commit
that referenced
this issue
May 4, 2020
* Use Zulu API v1 when upgrading Java Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes #714 Fixes #723 See Also #629 Signed-off-by: Ethan Dye <[email protected]> * Refuse to install 64-bit JDK on 32-bit OS armv8 builds in theory should work on the RPi3+/RPi4, however the current Raspbian kernel uses a armv7l base which works because armv8 is backwards compatible. However, this has the effect of making the builds targeting aarch64 provided by Azul unable to work on the RPi3+/RPi4. On the other hand, this is not a huge issue as the use of 64-bit Java on low-memory boards brings few benefits and mostly issues. Additionally, this adds checking for other platforms to ensure that the OS is actually 64-bit before trying to install a 64-bit JDK. If the OS is not actually 64-bit the installer defaults to installing a 32-bit JDK. Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 5, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 5, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 5, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 5, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 5, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 5, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 22, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 22, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
|
Going for Adopt 11 and Zulu 11 now, with Zulu 8 to remain the default for now. |
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 26, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 26, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 26, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
mstormi
pushed a commit
that referenced
this issue
May 26, 2020
* Add Option for AdoptOpenJDK Fixes #868 See Also #629 Signed-off-by: Ethan Dye <[email protected]> * Add Java 11 Support Signed-off-by: Ethan Dye <[email protected]> * Prepare Java for inclusion in openHABian image Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 26, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
mstormi
added a commit
to mstormi/openhabian
that referenced
this issue
May 27, 2020
* Add Option for AdoptOpenJDK Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]> Co-authored-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 27, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 27, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 28, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 29, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 30, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
mstormi
added a commit
that referenced
this issue
May 30, 2020
* Enhanced and more verbose testing in Travis (#859) * ZRAM tests to work if on ARM but lxc * cond_echo cmd in tryUntil() * restrict container to 1G for RPi3 * dont allow for failure of BATS tests * add warning 64bit on aarch64 is NOT supposed to work; check if OH downgrades to 32bit * reduce to a single shellcheck run (else builds succeed when there's no error in the last run) * increased verbosity on test cases Signed-off-by: Markus Storm <[email protected]> * Grafana/InfluxDB installation enhancements (#860) * Timeouts for service start #760 * Grafana admin password length is enforced #562 * Local installation of InfluxDB now also patches existing installations * Password reset for existing Grafana and local InfluxDB installations * In interactive mode, display a warning if less than 1GB RAM is detected Signed-off-by: Holger Friedrich <[email protected]> * Setting timezone based on IP geolocation now uses python3, fixes #862 (#864) * Switched installation of tzupdate to python3, as py2 is no longer supported cdown/tzupdate#34 Signed-off-by: Holger Friedrich <[email protected]> * Use Zulu API v1 when upgrading Java (#848) Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes #714 Fixes #723 See Also #629 Signed-off-by: Ethan Dye <[email protected]> * Refuse to install 64-bit JDK on 32-bit OS armv8 builds in theory should work on the RPi3+/RPi4, however the current Raspbian kernel uses a armv7l base which works because armv8 is backwards compatible. However, this has the effect of making the builds targeting aarch64 provided by Azul unable to work on the RPi3+/RPi4. On the other hand, this is not a huge issue as the use of 64-bit Java on low-memory boards brings few benefits and mostly issues. Additionally, this adds checking for other platforms to ensure that the OS is actually 64-bit before trying to install a 64-bit JDK. If the OS is not actually 64-bit the installer defaults to installing a 32-bit JDK. Signed-off-by: Ethan Dye <[email protected]> * fix nginx install (#867) * add missing #REDIR to nginx.conf template Signed-off-by: Markus Storm <[email protected]> * fix install webif port in docs (#873) Signed-off-by: Markus Storm <[email protected]> * hotfix to download aarch32hf instead of sf on multiple returns in Azul REST API (#877) Signed-off-by: Markus Storm <[email protected]> * point to new openHABian debug guide * point to new debug guide * Remove python2 from openHABian (#876) * replace all occurences of python and python-pip by python3 equivalent * fixes #875 (compatibility with Ubuntu 20.04) * timezone setting: added python3-setuptools before installing tzupdate * java installer: show version after install Signed-off-by: Holger Friedrich <[email protected]> * Run apt-get update on startup in background (#724) * move apt-get update to background on openhabian-config start, catch up in menu selections Signed-off-by: Markus Storm <[email protected]> * add intermediate output when selecting a menu option while apt-get update hasnt finished (#880) Signed-off-by: Markus Storm <[email protected]> * Use Markdown in LICENSE and update copyright year (#847) Co-authored-by: Thomas Dietrich <[email protected]> Signed-off-by: Ethan Dye <[email protected]> * Remove setting gnuio options on serial ports (#883) * Remove setting gnuio options on serial Signed-off-by: Markus Storm <[email protected]> * allow for disabling IPv6 in openhabian.conf (#888) * allow for ipv6=disable in openhabian.conf Signed-off-by: Markus Storm <[email protected]> * allow for ipv6=disable in openhabian.conf (#891) Signed-off-by: Markus Storm <[email protected]> * installation of additional bluetooth packages on RPi (#898) * python3-bluez not installed on stretch based installations, fixes #893 * additional bluetooth packages are now installed also on RPi4 Signed-off-by: Holger Friedrich <[email protected]> * Fix bluetooth package installation Signed-off-by: Holger Friedrich <[email protected]> * return instead of exit if installing non existent BT packages fails (#903) Signed-off-by: Markus Storm <[email protected]> * add hw,hwarch,release parameters (#901) * add hw, hwarch, release parameters to "fake" HW, OS Signed-off-by: Markus Storm <[email protected]> * added missing calls to apt-get update after adding repositories. (#911) Fixes grafana install issue, #906. Signed-off-by: Holger Friedrich <[email protected]> * Add openhab-cli backup/restore to menu 50 (#910) * added openhab-cli backup/restore implementation to 50 menu Signed-off-by: Markus Storm <[email protected]> * run Docker in foreground in BATS testing stage (#918) * run Docker in foreground in BATS testing stage to get to see output in Travis builds * allow for dev and BATS testing stages to fail while BATS tests still fail Signed-off-by: Markus Storm <[email protected]> * CORS fix (#830) * fix CORS (#528) Signed-off-by: Markus Storm <[email protected]> * Grafana installation fixed (#915) * wait for Grafana service to setup grafana.db before using grafana-cli to avoid side effects, fixes #914 * adapted bats test to check connection to InfluxDB, to store settings in Grafana, to validate connection and settings file grafana.db Signed-off-by: Holger Friedrich <[email protected]> * Grafana installation fixed (#925) * race condition due to db migration during installer run, #921 Signed-off-by: Holger Friedrich <[email protected]> * add RPi4 to bluetooth and WiFi functions; add CM1,CM3(+) support (#861) * Add CM1,CM3(+) to supported models so now we support all RPis * add RPi4 to bluetooth and WiFi functions * add disable-wifi to option 36 Signed-off-by: Markus Storm <[email protected]> * another instance of safe grep'ing (#929) * fix another safe grep instance Signed-off-by: Markus Storm <[email protected]> * Insert missing semi-colons Signed-off-by: Ethan Dye <[email protected]> * Fixes in preparation of upcoming changes (#932) * Fixes in preparation of upcoming changes Signed-off-by: Ethan Dye <[email protected]> * replace fstab by explicit systemd mount units to ensure proper order (#807) * Replace fstab by explicit systemd units to ensure right mount order (#807) To ensure ZRAM and Samba properly work together on sharing /srv/openhab2-*, we need to change the order of mounts. As this cannot be done in fstab, I removed them and setup separate systemd mount units instead. * change Samba shares Include logs, exclude /srv overview share, remove Samba defaults like printers Signed-off-by: Markus Storm <[email protected]> * intro stable branch (#882) * introduce stable branch (#882) * renamed mode parameter to debugmode; new values are off/on/maximum * Add popup announcement function * add docs/NEWSLOG.md Signed-off-by: Markus Storm <[email protected]> Co-authored-by: Holger Friedrich <[email protected]> Co-authored-by: Ethan Dye <[email protected]> Co-authored-by: Holger Friedrich <[email protected]>
mstormi
pushed a commit
to mstormi/openhabian
that referenced
this issue
May 30, 2020
* Use Zulu API v1 when upgrading Java Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]> * Refuse to install 64-bit JDK on 32-bit OS armv8 builds in theory should work on the RPi3+/RPi4, however the current Raspbian kernel uses a armv7l base which works because armv8 is backwards compatible. However, this has the effect of making the builds targeting aarch64 provided by Azul unable to work on the RPi3+/RPi4. On the other hand, this is not a huge issue as the use of 64-bit Java on low-memory boards brings few benefits and mostly issues. Additionally, this adds checking for other platforms to ensure that the OS is actually 64-bit before trying to install a 64-bit JDK. If the OS is not actually 64-bit the installer defaults to installing a 32-bit JDK. Signed-off-by: Ethan Dye <[email protected]> Signed-off-by: Markus Storm <[email protected]>
mstormi
pushed a commit
to mstormi/openhabian
that referenced
this issue
May 31, 2020
* Use Zulu API v1 when upgrading Java Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]> * Refuse to install 64-bit JDK on 32-bit OS armv8 builds in theory should work on the RPi3+/RPi4, however the current Raspbian kernel uses a armv7l base which works because armv8 is backwards compatible. However, this has the effect of making the builds targeting aarch64 provided by Azul unable to work on the RPi3+/RPi4. On the other hand, this is not a huge issue as the use of 64-bit Java on low-memory boards brings few benefits and mostly issues. Additionally, this adds checking for other platforms to ensure that the OS is actually 64-bit before trying to install a 64-bit JDK. If the OS is not actually 64-bit the installer defaults to installing a 32-bit JDK. Signed-off-by: Ethan Dye <[email protected]> Signed-off-by: Markus Storm <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 31, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 31, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
ecdye
added a commit
to ecdye/openhabian
that referenced
this issue
May 31, 2020
Fixes openhab#868 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]>
mstormi
pushed a commit
that referenced
this issue
May 31, 2020
* Add Option for AdoptOpenJDK Fixes #868 See Also #629 * Add Java 11 Support * Prepare Java for inclusion in openHABian image Signed-off-by: Ethan Dye <[email protected]>
mstormi
pushed a commit
to mstormi/openhabian
that referenced
this issue
Jun 10, 2020
* Use Zulu API v1 when upgrading Java Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]> * Refuse to install 64-bit JDK on 32-bit OS armv8 builds in theory should work on the RPi3+/RPi4, however the current Raspbian kernel uses a armv7l base which works because armv8 is backwards compatible. However, this has the effect of making the builds targeting aarch64 provided by Azul unable to work on the RPi3+/RPi4. On the other hand, this is not a huge issue as the use of 64-bit Java on low-memory boards brings few benefits and mostly issues. Additionally, this adds checking for other platforms to ensure that the OS is actually 64-bit before trying to install a 64-bit JDK. If the OS is not actually 64-bit the installer defaults to installing a 32-bit JDK. Signed-off-by: Ethan Dye <[email protected]> Signed-off-by: Markus Storm <[email protected]>
mstormi
pushed a commit
to mstormi/openhabian
that referenced
this issue
Jun 10, 2020
* Add Option for AdoptOpenJDK Fixes openhab#868 See Also openhab#629 * Add Java 11 Support * Prepare Java for inclusion in openHABian image Signed-off-by: Ethan Dye <[email protected]> Signed-off-by: Markus Storm <[email protected]>
mstormi
pushed a commit
to mstormi/openhabian
that referenced
this issue
Jun 10, 2020
* Use Zulu API v1 when upgrading Java Additionally, to clarify what Java version this will install, when available, the API will prefer downloading a JRE. However, when a JRE is not available it will use a JDK instead. However, when JDK's are installed only the essential binaries are linked to update-alternatives so extra JDK related software is unlinked (i.e. javac). At the moment, Azul appears to only provide JDK builds for ARM platforms and so, as such, ARM platforms are most often the ones to not get a JRE installed and the resulting installation tends to be a bit larger (~100 MB). One minor inconvenience is that with the current Azul API it does not allow explicitly choosing builds without the JavaFX additional binaries. So at times, the Java version installed will have extra JavaFX binaries. This is usually seen when the architecture being installed is x86 based. Fixes openhab#714 Fixes openhab#723 See Also openhab#629 Signed-off-by: Ethan Dye <[email protected]> * Refuse to install 64-bit JDK on 32-bit OS armv8 builds in theory should work on the RPi3+/RPi4, however the current Raspbian kernel uses a armv7l base which works because armv8 is backwards compatible. However, this has the effect of making the builds targeting aarch64 provided by Azul unable to work on the RPi3+/RPi4. On the other hand, this is not a huge issue as the use of 64-bit Java on low-memory boards brings few benefits and mostly issues. Additionally, this adds checking for other platforms to ensure that the OS is actually 64-bit before trying to install a 64-bit JDK. If the OS is not actually 64-bit the installer defaults to installing a 32-bit JDK. Signed-off-by: Ethan Dye <[email protected]> Signed-off-by: Markus Storm <[email protected]>
mstormi
pushed a commit
to mstormi/openhabian
that referenced
this issue
Jun 10, 2020
* Add Option for AdoptOpenJDK Fixes openhab#868 See Also openhab#629 * Add Java 11 Support * Prepare Java for inclusion in openHABian image Signed-off-by: Ethan Dye <[email protected]> Signed-off-by: Markus Storm <[email protected]>
|
@ecdye would you say we're done with this ? |
|
Yeah, It has been implemented and so far seems to be solid so I think we are done. |
|
Great. Thanks again for your contribution. |
|
Glad to hear that it is working for you. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are discussion on updating JAVA for openHAB 3.0 to at least JAVA 11.
openhab/openhab-distro#768
Nothing new really, just update the packages when times come.
Java Zulu are providing 32-bit packages so we don't need to drop support for older RPis.
The text was updated successfully, but these errors were encountered: