openjdk11 (and possibly openjdk12) needs to be integrated into bsd.java.mk. Currently, JAVA_VERSION=11 is not recognised (yes, yes, I know 1.8+ can be used), and currently fails with: Makefile error: "11" is not a valid value for JAVA_VERSION. It should be one or more of: 1.6 1.7 1.8 1.9 (with an optional "+" suffix.) *** Error code 1
+1 to this. Can someone work on this?
I'd also like to see bsd.java.mk updated. It's about two generations behind the current USES infrastructure and would really benefit from some work there as well. Adding 11 and 12 supported shouldn't block on that though.
Created attachment 204462 [details] patch for bsd.java.mk to account for JDK11 & JDK12 Would someone please test attached patch to allow use of the following in make.conf: JAVA_VERSION=12.0 JAVA_VENDOR=openjdk It seems to work for me on 11.2-RELEASE-p10 r347635 Thanks!
Created attachment 204463 [details] patch for bsd.java.mk to account for JDK11 & JDK12
Hi Tommy, Thanks for the patch. When you say that it works for you, can you please share what testing you did? I'll be travelling for the next few days and hope to get back to this after that.
(In reply to Greg Lewis from comment #5) Hi Greg, Without the patch, specifying any of the below would cause errors during building of various ports using Java: JAVA_VERSION=12 JAVA_VERSION=12.0 The patch conforms to previous JAVA_VERSION usage: 1.6 1.7 1.8 11.0 12.0 Using JAVA_VERSION=12.0 and JAVA_VENDOR=openjdk allow my systems to have only 1 JDK. I haven't tried using only 12.0+ yet but the regex pattern should match and also allow future versions 11.1 or 12.1 with minor changes. Any existing ports specifying JAVA_VERSION=1.8+ would build such as sysutils/facter (for sysutils/puppet6) with additional patches: *) BR 237991 - java/openjdk12 is missing java wrapper for RUN_DEPENDS in Makefile which provides various java commands in /usr/local/bin. java/openjdk11 is also missing the wrapper. If JDK12 is the only java tool available, any app searching for java commands in the path would fail to execute and ports would also failed to build. Of the 3 OpenJDKs 8, 11, 12, only 8 provides the wrapper. *) BR 237990 - sysutils/facter specifies '-soucre 1.6' but JDK12 requires '-source 7' I've done some spot tests with Tomcat 9.0.20 various (Servlet, JSP, and WebSocket) examples without any issue. This is the server information reported by Tomcat's manager: Tomcat Version JVM Version JVM Vendor OS Name OS Version OS Architecture Hostname IP Address Apache Tomcat/9.0.20 12+12-2 Oracle Corporation FreeBSD 11.2-RELEASE-p10 amd64 freebsd.test.domain 10.x.x.x Snippets from /usr/local/etc/rc.d/puppet* : ${puppetdb_java_home="/usr/local/openjdk12"} : ${puppetserver_java_home="/usr/local/openjdk12"} And puppetserver does run with default config as seen from log: 2019-05-21T13:58:53.400-07:00 INFO [async-dispatch-2] [o.e.j.s.AbstractConnector] Started ServerConnector@e3c57e4{SSL,[ssl, http/1.1]}{0.0.0.0:8140} 2019-05-21T13:58:53.401-07:00 INFO [async-dispatch-2] [o.e.j.s.Server] Started @56880ms 2019-05-21T13:58:53.415-07:00 INFO [async-dispatch-2] [p.t.s.s.status-core] Starting background monitoring of cpu usage metrics 2019-05-21T13:58:53.440-07:00 INFO [async-dispatch-2] [p.t.s.s.status-service] Registering status callback function for service 'status-service', version 1.1.0 2019-05-21T13:58:53.445-07:00 INFO [async-dispatch-2] [p.t.s.s.status-service] Registering status service HTTP API at /status 2019-05-21T13:58:53.478-07:00 INFO [async-dispatch-2] [o.e.j.s.h.ContextHandler] Started o.e.j.s.h.ContextHandler@1e55980e{/status,null,AVAILABLE} 2019-05-21T13:58:53.546-07:00 INFO [async-dispatch-2] [p.s.m.master-service] Puppet Server has successfully started and is now ready to handle requests 2019-05-21T13:58:53.549-07:00 INFO [async-dispatch-2] [p.s.l.legacy-routes-service] The legacy routing service has successfully started and is now ready to handle requests 2019-05-21T13:58:53.556-07:00 INFO [async-dispatch-2] [p.s.a.analytics-service] Puppet Server Update Service has successfully started and will run in the background I'm aware of only one major issue with puppet is that I think the major changes FreeBSD 12 in how the OS handles filesystem hooks breaking jruby. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233766 Because of that, I'm holding back on upgrade to 12.0 :(
(In reply to Greg Lewis from comment #5) Hi Greg, I just did a test build of www/tomcat9 with poudriere using most of the default port config options with the following for make.conf DEFAULT_VERSIONS+=bind=9.13 bdb=6 DEFAULT_VERSIONS+=mysql=10.3m pgsql=11 samba=4.8 ssl=openssl111 DEFAULT_VERSIONS+=perl5=5.28 python=3.7 python2=2.7 python3=3.7 ruby=2.5 tcltk=8.7 DEFAULT_VERSIONS+=apache=2.4 php=7.3 php:web=7.3 php_web=7.3 php-web=7.3 WITH_BDB6_PERMITTED=YES JAVA_VERSION=12.0+ OPTIONS_UNSET+=X11 DOXYGEN TESTS TEST OPTIONS_UNSET+=DOCS MANPAGES EXAMPLES [10:13:38] Built ports: ports-mgmt/pkg ... java/openjdk12 devel/jakarta-commons-daemon www/tomcat9 [11amd64-default-test] [2019-05-21_14h31m21s] [committing:] Queued: 121 Built: 121 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 10:13:32
Please don't mix Java version with JVM version. The Java version remains 12, even if the JVM version is at 12.2.
(In reply to Michael Osipov from comment #8) Hi Michael, Would you please elaborate? Are you referring to '12+12-2' of the reported JVM version? 23-May-2019 00:52:56.762 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/local/openjdk12 23-May-2019 00:52:56.762 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 12+12-2 If so, that was provided in java/openjdk12/Makefile under CONFIGURE_ARGS: --with-version-string=${JDK_MAJOR_VERSION}+${JDK_BUILD_NUMBER}-${BSD_JDK_VERSION} \
(In reply to Tommy P from comment #9) Please see: > [mosipov@mika-ion ~]$ for java_version in 8 11 12 ; do echo "Java version: $java_version" ; JAVA_HOME=/usr/local/openjdk$java_version mvn help:system | grep -E '^java\.(.+\.)?version' | sort ; done > Java version: 8 > java.class.version=52.0 > java.runtime.version=1.8.0_212-b04 > java.specification.version=1.8 > java.version=1.8.0_212 > java.vm.specification.version=1.8 > java.vm.version=25.212-b04 > Java version: 11 > java.class.version=55.0 > java.runtime.version=11.0.3+7-1 > java.specification.version=11 > java.version.date=2019-04-16 > java.version=11.0.3 > java.vm.specification.version=11 > java.vm.version=11.0.3+7-1 > Java version: 12 > java.class.version=56.0 > java.runtime.version=12+12-1 > java.specification.version=12 > java.version.date=2019-04-16 > java.version=12 > java.vm.specification.version=12 > java.vm.version=12+12-1 My understanding is that each 'java.vm.specification.version' which is the JDK version won't change within this major release. Especially with Oracle's 6 month release cycle it is very unlikely that one will see 12.1 as a last update for JDK 12. New feature will be in n+1 where n in a major version. LTS versions won't receive new features in most cases and wil stay with patch versions. But even if they do, they will immediate stop suppporting n.y-0.1 and require you to run n.y. That is by I would keep everything from 11 as integers and not as fractions.
(In reply to Michael Osipov from comment #10) Ah... Thank you for clarifying. Since Java 9: $FEATURE.$INTERIM.$UPDATE.$PATCH $FEATURE — The feature-release counter, incremented for every feature release regardless of release content. Features may be added in a feature release; they may also be removed, if advance notice was given at least one feature release ahead of time. Incompatible changes may be made when justified. $INTERIM — The interim-release counter, incremented for non-feature releases that contain compatible bug fixes and enhancements but no incompatible changes, no feature removals, and no changes to standard APIs. $UPDATE — The update-release counter, incremented for compatible update releases that fix security issues, regressions, and bugs in newer features. $PATCH — The emergency patch-release counter, incremented only when it's necessary to produce an emergency release to fix a critical issue. per JavaDoc: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Runtime.Version.html Thus, I presume you're suggesting to use $FEATURE then? I agree.
(In reply to Tommy P from comment #11) Correct, that's I would do. As you can see even $INTERIM won't introduce anything new beside non-fuctional backports and fixes.
(In reply to Michael Osipov from comment #12) I already updated the patch for Mk/bsd.java.mk to look for: 1.6[+] 1.7[+] 1.8[+] 9[+] 11[+] 12[+] I'm currently testing to verify that JAVA_VERSION=1.8+ and JAVA_VERSION=12+ would work as expected. I've already submitted a patch for the javavmwrapper to look for the same (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223304).
(In reply to Tommy P from comment #13) I wouldn't even bother to add 9+ because 1) it is dead, 2) there is no FreeBSD port for.
I think there is something wrong with the original bsd.java.mk. I here's my make.conf in my VM build server: CPUTYPE?=amdfam10 KERNCONF=Custom CFLAGS+= -msse3 -msse4a -msse4.1 -msse4.2 -m3dnow CXXFLAGS+= -msse3 -msse4a -msse4.1 -msse4.2 -m3dnow COPTFLAGS= -O2 -pipe DOC_LANG= en_US.ISO8859-1 HOST_NAME!= /bin/hostname -s DEFAULT_VERSIONS+=bind=9.14 bdb=6 DEFAULT_VERSIONS+=mysql=10.3m pgsql=11 samba=4.8 ssl=openssl111 DEFAULT_VERSIONS+=perl5=5.28 python=3.7 python2=2.7 python3=3.7 ruby=2.6 tcltk=8.7 DEFAULT_VERSIONS+=apache=2.4 .if ${HOST_NAME} == 11amd64-default-testphp DEFAULT_VERSIONS+=php=7.2 php:web=7.2 php_web=7.2 php-web=7.2 .else DEFAULT_VERSIONS+=php=7.3 php:web=7.3 php_web=7.3 php-web=7.3 .endif WITH_BDB6_PERMITTED=YES JAVA_VERSION=1.6 .if ${HOST_NAME} == 11amd64-default-test JAVA_VERSION=11.0 .elif ${HOST_NAME} == 11amd64-default-test16 JAVA_VERSION=1.6 .elif ${HOST_NAME} == 11amd64-default-test18 JAVA_VERSION=1.8 .elif ${HOST_NAME} == 11amd64-default-test11 JAVA_VERSION=11.0 .elif ${HOST_NAME} == 11amd64-default-test12 JAVA_VERSION=12.0 .elif ${HOST_NAME} == 11amd64-default-server JAVA_VERSION=11.0 .endif OPTIONS_UNSET+=X11 DOXYGEN TESTS TEST OPTIONS_UNSET+=DOCS MANPAGES EXAMPLES ----------------------------------------------------------------------------- My dry run in poudriere for www/nextcloud is correct: root@d-build-fbsd11:~ # poudriere bulk -j 11amd64 -p default -z testphp -n www/nextcloud [00:00:00] [Dry Run] Creating the reference jail... done [00:00:03] [Dry Run] Mounting system devices for 11amd64-default-testphp ... [00:00:11] [Dry Run] Dry run mode, cleaning up and exiting [00:00:11] [Dry Run] Would build 90 packages using 40 builders [00:00:11] [Dry Run] Ports to build: archivers/libarchive ... lang/php72 lang/python27 lang/python37 ... www/libnghttp2 www/nextcloud www/php72-opcache www/php72-session x11-fonts/fontconfig [00:00:11] [Dry Run] Logs: /poudriere/data/logs/bulk/11amd64-default-testphp/2019-05-25_18h13m54s [00:00:11] [Dry Run] Cleaning up However, for archivers/jzlib having this in Makefile doesn't work: USE_JAVA= yes JAVA_VERSION= 1.6+ NO_ARCH= yes root@d-build-fbsd11:~ # poudriere bulk -j 11amd64 -p default -z test16 -n archivers/jzlib [00:00:01] [Dry Run] Creating the reference jail... done [00:00:04] [Dry Run] Mounting system devices for 11amd64-default-test16 ... [00:00:14] [Dry Run] Dry run mode, cleaning up and exiting [00:00:14] [Dry Run] Would build 116 packages using 40 builders [00:00:14] [Dry Run] Ports to build: archivers/jzlib ... java/bootstrap-openjdk8 java/java-zoneinfo java/javavmwrapper java/openjdk8 .... [00:00:14] [Dry Run] Logs: /poudriere/data/logs/bulk/11amd64-default-test16/2019-05-25_18h13m16s [00:00:14] [Dry Run] Cleaning up shouldn't it build java/openjdk6 ?
Running outside of poudriere is the same: root@d-build-fbsd11:/usr/ports/archivers/jzlib # grep JAVA Makefile USE_JAVA= yes JAVA_VERSION= 1.6+ ${JAVAC} -classpath ${WRKSRC}/src/main/java ${INSTALL_DATA} ${JAR_FILE} ${STAGEDIR}/${JAVAJARDIR}/${PORTNAME}.jar root@d-build-fbsd11:/usr/ports/archivers/jzlib # make all-depends-list|grep 'jdk' /poudriere/ports/default/java/openjdk8 /poudriere/ports/default/java/bootstrap-openjdk8
Interestingly enough, the same make.conf used for apache-ant: root@d-build-fbsd11:/usr/ports/devel/apache-ant # grep JAVA Makefile USE_JAVA= yes DATADIR= ${JAVASHAREDIR}/${PORTNAME} root@d-build-fbsd11:/usr/ports/devel/apache-ant # make all-depends-list|grep 'jdk' /poudriere/ports/default/java/openjdk6 /poudriere/ports/default/java/bootstrap-openjdk6 Then I changed the JAVA_VERSION=1.8 root@d-build-fbsd11:/usr/ports/devel/apache-ant # make all-depends-list | grep 'jdk' /poudriere/ports/default/java/openjdk8 /poudriere/ports/default/java/bootstrap-openjdk8
Your previous examples look correct, IIRC. A specification of "1.6+" means any version of Java which is Java 6 or newer. If a version of Java is not installed that should result in it picking the default version of Java (if it is newer than Java 6). The concerning one is the example of apache-ant picking Java 6. It should be picking Java 8 if the specification is just "USE_JAVA=yes" since Java 8 is currently the default version.
(In reply to Greg Lewis from comment #18) I understand about + specified in the JAVA_VERSION of the port. But when JAVA_VERSION=1.6 is specified in make.conf, shouldn't it build using java/openjdk6 and that it also complies with the port requirement of 1.6+? If not and selects the latest available ie java/openjdk8, then I think we may have a problem. Since JDK 11 is LTS and many would want to use that in production, how can we explicitly specify to use JDK 11 then and not automatically select 12 because it's the most current? I see another use case for explicit version: deskutils/nextcloudclient/Makefile:50:BROKEN= nextcloudclient requires OpenSSL 1.1.0, add DEFAULT_VERSIONS+=ssl=openssl111 to /etc/make.conf www/squid3/Makefile:284:BROKEN= Does not build on FreeBSD 12 with OpenSSL 1.1. You may add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf as a workaround
Created attachment 204640 [details] patch for bsd.default-versions.mk and bsd.java.mk DISCLAIMER: *) Please review the patch, especially, under section # Error checking: JAVA_VERSION. My C/C++ skills haven't been used in a very long time and is very rusty still. I'm not sure I have 'test' right. *) Oracle OpenJDK 9 is removed as suggested by Michael Osipov in addition to not a LTS version. *) I don't know if this is proper way to facilitate DEFAULT_VERSIONS in the backend but it works :) *) Beware that using most current JDK would break some ports ie BR 237990 - sysutils/facter specifies '-soucre 1.6' but JDK12 requires '-source 7' Currently: *) Unable to use a specific Java version and automatically selects most current available 1.8 *) Missing JDK 11 & 12 Patches: *) Allow use specific version via DEFAULT_VERSIONS+=java=11 Possible values: 1.6 1.7 1.8 11 12 *) Not specifying DEFAULT_VERSIONS will use default 11 since it's the most current LTS. *) If DEFAULT_VERSIONS is less then port's required minimum, there should be a warning to user and use the port's instead. ------------------------------------------------------------- root@d-build-fbsd11:/usr/ports/www/tomcat9 # make java-debug # User specified parameters: JAVA_VERSION= 1.8+ (1.8 11 12) JAVA_OS= (native linux) JAVA_VENDOR= (openjdk oracle) JAVA_BUILD= JAVA_RUN= jre JAVA_EXTRACT= JAVA_VERSION_MIN= 1.8 JAVA_DEFAULT= 11 # JDK port dependency selection process: _JAVA_PORTS_POSSIBLE= JAVA_PORT_NATIVE_OPENJDK_JDK_12 JAVA_PORT_NATIVE_OPENJDK_JDK_11 JAVA_PORT_NATIVE_OPENJDK_JDK_1_8 JAVA_PORT_LINUX_ORACLE_JDK_1_8 _JAVA_PORTS_INSTALLED= _JAVA_PORTS_INSTALLED_POSSIBLE= _JAVA_PORT= JAVA_PORT_NATIVE_OPENJDK_JDK_11 _JAVA_PORT_INFO= PORT=java/openjdk11 HOME=/usr/local/openjdk11 VERSION=11 OS=native VENDOR=openjdk # Selected JDK port: JAVA_PORT= java/openjdk11 JAVA_HOME= /usr/local/openjdk11 JAVA_PORT_VERSION= 11 JAVA_PORT_OS= native (Native) JAVA_PORT_VENDOR= openjdk (OpenJDK BSD Porting Team) # Additional variables: JAVAC= JAVA_CLASSES= /usr/local/openjdk11/jre/lib/rt.jar root@d-build-fbsd11:/usr/ports/www/tomcat9 # make all-depends-list|grep jdk /poudriere/ports/default/java/openjdk11 /poudriere/ports/default/java/bootstrap-openjdk11
I just tried building the entire ports tree and run into 2 errors thus far: databases/mysql-connector-java51 => JAVA_VERSION= 1.6 1.7 1.8 news/nzbhydra2 => JAVA_VERSION= 1.8 1.9 1.10 1.11 Are the above ports using the versioning correctly? Shouldn't it be 1.6+ and 1.8+ respectively per man of javavm (even though outdated). Currently allowed versions are `1.5', `1.5+', `1.6', `1.6+', `1.7' and `1.7+'.
(In reply to Tommy P from comment #19) Please don't make this assumption. Both 8 and 11 are LTS versions and I am quite confident that many people will still stick to 8 for many years to come because 11 is too disruptive for some at the moment.
(In reply to Tommy P from comment #21) Both entries look wrong. MySQL 5.1 is way out of support. 1.10, 1.11 simply do not exist and are wrong assumptions by the port maintainer.
(In reply to Michael Osipov from comment #22) I know that Java 8 is LTS. I'm unable to find anything concrete regarding EOL for OpenJDK 8. "OpenJDK 8u242 Thursday, August 29th 2019: jdk8u-dev forest open (tag: jdk8u242-b00)" from https://wiki.openjdk.java.net/display/jdk8u/Main As for Oracle JDK, "Oracle will continue to provide free public updates and auto updates of Java SE 8, until at least the end of December 2020 for Personal, Development and other Users. ... As of the April 16, 2019 quarterly critical patch update, Oracle Customers should access updates to Java SE 8 for commercial use from Oracle through My Oracle Support and via auto update where applicable." from https://www.oracle.com/technetwork/java/java-se-support-roadmap.html It appears the cut off date available to public for both is likely end of 2020. Which is about 18 more months. While default version 11 is my recommendation, it's easy for the maintainer to change it 1.8 in one line. From 8 to 11, the following features/functionalities were removed/deprecated that may break certain functionalities: 9) JavaDB (aka Apache Derby) 10) javah tool 11) JavaFX, JavaEE, Corba removed from JDK Depecrated Nashorn JavaScript engine IMO, I think it's worthwhile upgrade for TLS 1.3 in addition to other GC improvements.
(In reply to Tommy P from comment #24) See here: https://www.redhat.com/en/about/press-releases/leadership-openjdk-8-and-openjdk-11-transitions-red-hat Red Hat is maintaining OpenJDK 8 for the years to come. Also do not confuse Oracle JDK with OpenJDK. Their statements apply to Oracle JDK only.
(In reply to Michael Osipov from comment #25) I'm not confused about OpenJDK vs Oracle JDK vs Oracle OpenJDK. Like I said before about nothing concrete on OpenJDK' EOL. The link you've cited states only the transfer of stewardship from Oracle to Red Hat. I think we should stop here since I don't think this is the right platform for lengthy discussions about which version is better and SDLC's best practices. The main goals of my proposed patch are: 1) Specific version usage for different use cases I've mentioned previously similar to OpenSSL 2) Added versions 11 & 12 for the pioneers 3) The default version is for those taking the minimalist configuration / customization approach. Thus, regardless of whichever version the porting team decides to use as default, the patch would provide anyone the freedom to choose for her/his scenarios.
(In reply to Tommy P from comment #26) Agreed, thank you for your work.
Tommy, thanks for all the work on this. I've been working on this a little while I've been offline. I'll attach what I have and comment on it tomorrow. I need to pull in some of the changes you have as well.
Created attachment 204819 [details] Changes for bsd.java.mk
Bug 238758 requested an exp run for these changes, which was successful. I plan to commit them on Monday once the javavmwrapper changes have settled.
A commit references this bug: Author: glewis Date: Wed Jul 31 16:06:31 UTC 2019 New revision: 507714 URL: https://svnweb.freebsd.org/changeset/ports/507714 Log: Support newer Java versions * Add configuration for newer versions of the JDK (11, 12) * Switch to modern Java versioning (e.g. 8 rather than 1.8) * Retain backwards compatibility with existing version specification * Support the few ports that set USE_JAVA to the requested version PR: 237054, 238758 (exp-run) Changes: head/Mk/bsd.java.mk
Support for 11 and 12 has been added to bsd.java.mk.