Bug 237054 - java/openjdk11: Needs to be integrated into bsd.java.mk
Summary: java/openjdk11: Needs to be integrated into bsd.java.mk
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Greg Lewis
Depends on:
Reported: 2019-04-05 20:16 UTC by Jonathan Chen
Modified: 2020-03-24 07:55 UTC (History)
7 users (show)

See Also:
koobs: maintainer-feedback+

patch for bsd.java.mk to account for JDK11 & JDK12 (3.38 KB, text/plain)
2019-05-19 06:29 UTC, Tommy P
no flags Details
patch for bsd.java.mk to account for JDK11 & JDK12 (3.38 KB, patch)
2019-05-19 06:49 UTC, Tommy P
no flags Details | Diff
patch for bsd.default-versions.mk and bsd.java.mk (9.05 KB, patch)
2019-05-27 04:41 UTC, Tommy P
no flags Details | Diff
Changes for bsd.java.mk (4.49 KB, patch)
2019-06-04 14:17 UTC, Greg Lewis
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Chen 2019-04-05 20:16:22 UTC
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
Comment 1 Koichiro Iwao freebsd_committer 2019-04-21 10:59:47 UTC
+1 to this. Can someone work on this?
Comment 2 Greg Lewis freebsd_committer 2019-04-25 15:08:03 UTC
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.
Comment 3 Tommy P 2019-05-19 06:29:41 UTC
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:


It seems to work for me on 11.2-RELEASE-p10 r347635

Comment 4 Tommy P 2019-05-19 06:49:15 UTC
Created attachment 204463 [details]
patch for bsd.java.mk to account for JDK11 & JDK12
Comment 5 Greg Lewis freebsd_committer 2019-05-21 17:54:02 UTC
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.
Comment 6 Tommy P 2019-05-21 21:33:03 UTC
(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:


The patch conforms to previous JAVA_VERSION usage:


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]}{}
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.


Because of that, I'm holding back on upgrade to 12.0 :(
Comment 7 Tommy P 2019-05-22 09:22:16 UTC
(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




[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
Comment 8 Michael Osipov 2019-05-22 11:08:02 UTC
Please don't mix Java version with JVM version. The Java version remains 12, even if the JVM version is at 12.2.
Comment 9 Tommy P 2019-05-23 18:34:35 UTC
(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} \
Comment 10 Michael Osipov 2019-05-23 19:01:30 UTC
(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.
Comment 11 Tommy P 2019-05-23 20:23:09 UTC
(In reply to Michael Osipov from comment #10)
Ah... Thank you for clarifying.  Since Java 9:


    $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.
Comment 12 Michael Osipov 2019-05-23 20:50:09 UTC
(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.
Comment 13 Tommy P 2019-05-23 21:52:18 UTC
(In reply to Michael Osipov from comment #12)
I already updated the patch for Mk/bsd.java.mk to look for:


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).
Comment 14 Michael Osipov 2019-05-23 22:00:57 UTC
(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.
Comment 15 Tommy P 2019-05-26 01:29:37 UTC
I think there is something wrong with the original bsd.java.mk.  I here's my make.conf in my VM build server:

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
.if ${HOST_NAME} == 11amd64-default-testphp
  DEFAULT_VERSIONS+=php=7.2 php:web=7.2 php_web=7.2 php-web=7.2
  DEFAULT_VERSIONS+=php=7.3 php:web=7.3 php_web=7.3 php-web=7.3
.if ${HOST_NAME} == 11amd64-default-test
.elif ${HOST_NAME} == 11amd64-default-test16
.elif ${HOST_NAME} == 11amd64-default-test18
.elif ${HOST_NAME} == 11amd64-default-test11
.elif ${HOST_NAME} == 11amd64-default-test12
.elif ${HOST_NAME} == 11amd64-default-server

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
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 ?
Comment 16 Tommy P 2019-05-26 02:58:40 UTC
Running outside of poudriere is the same:

root@d-build-fbsd11:/usr/ports/archivers/jzlib # grep JAVA Makefile
USE_JAVA=       yes
                ${JAVAC} -classpath ${WRKSRC}/src/main/java

root@d-build-fbsd11:/usr/ports/archivers/jzlib # make all-depends-list|grep 'jdk'
Comment 17 Tommy P 2019-05-26 03:46:51 UTC
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

root@d-build-fbsd11:/usr/ports/devel/apache-ant # make all-depends-list|grep 'jdk'

Then I changed the JAVA_VERSION=1.8

root@d-build-fbsd11:/usr/ports/devel/apache-ant # make all-depends-list | grep 'jdk'
Comment 18 Greg Lewis freebsd_committer 2019-05-26 04:28:28 UTC
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.
Comment 19 Tommy P 2019-05-26 07:29:44 UTC
(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
Comment 20 Tommy P 2019-05-27 04:41:48 UTC
Created attachment 204640 [details]
patch for bsd.default-versions.mk and bsd.java.mk

*) 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'

*) Unable to use a specific Java version and automatically selects most current available 1.8
*) Missing JDK 11 & 12 

*) 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_RUN=                       jre

JAVA_VERSION_MIN=               1.8
JAVA_DEFAULT=                   11

# JDK port dependency selection process:
_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:
JAVA_CLASSES=                   /usr/local/openjdk11/jre/lib/rt.jar

root@d-build-fbsd11:/usr/ports/www/tomcat9 # make all-depends-list|grep jdk
Comment 21 Tommy P 2019-05-27 06:45:30 UTC
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+'.
Comment 22 Michael Osipov 2019-05-27 07:06:44 UTC
(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.
Comment 23 Michael Osipov 2019-05-27 07:10:13 UTC
(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.
Comment 24 Tommy P 2019-05-27 10:05:56 UTC
(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.
Comment 25 Michael Osipov 2019-05-27 10:46:45 UTC
(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.
Comment 26 Tommy P 2019-05-27 12:51:31 UTC
(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.
Comment 27 Michael Osipov 2019-05-27 13:22:01 UTC
(In reply to Tommy P from comment #26)

Agreed, thank you for your work.
Comment 28 Greg Lewis freebsd_committer 2019-06-04 14:16:01 UTC
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.
Comment 29 Greg Lewis freebsd_committer 2019-06-04 14:17:02 UTC
Created attachment 204819 [details]
Changes for bsd.java.mk
Comment 30 Greg Lewis freebsd_committer 2019-07-26 19:09:31 UTC
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.
Comment 31 commit-hook freebsd_committer 2019-07-31 16:07:31 UTC
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

  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)

Comment 32 Greg Lewis freebsd_committer 2019-07-31 16:09:39 UTC
Support for 11 and 12 has been added to bsd.java.mk.