20:09 Rene Ladan (rene) 

cleanup: remove expired versions of OpenJDK (12 through 16)

Adjust ports depending on expired versions of OpenJDK:
- biology/snpeff: 12+ -> 17+
- devel/RStudio: 12 -> 11
- www/closure-compiler: 13 -> 11+

Allow java/openjdk17 to use java/openjdk17-bootstrap on i386
too, this builds just fine on 13.1-i386

Remove jdk12-doc as it is no longer relevant.

Clean up Java version calculations in bsd.java.mk

Reviewed by: jwb, java (glewis)

Differential Revision: https://reviews.freebsd.org/D35280

    c7d1c24

02:28 Greg Lewis (glewis) 

java/openjdk13: Update to 13.0.11 GA

    29591ea

08:24 Baptiste Daroussin (bapt) 

openjdk: mark as deprecated all EOLed version of openjdk

The current supported version of openjdk are:
8 (LTS) up to 31 march 2025
11 (LTS) up to 30 september 2026
17 (LTS) up to 20 september 2031
18 up to 30 september 2022

All other version have expired long ago

    fe30b51

07:56 Dimitry Andric (dim) 

java/openjdk13 java/openjdk14 java/openjdk15 java/openjdk16 java/openjdk17
java/openjdk17-jre: fix build with clang 14

During an exp-run for llvm 14 (see bug 261742), it turned out that
java/openjdk13 and java/openjdk17 fail to build with clang 14 (but this
also affects openjdk14 through 16):

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_serviceThread.o:
/wrkdirs/usr/ports/java/openjdk13/work/jdk13u-jdk-13.0.10-5-1/src/hotspot/share/runtime/serviceThread.cpp:133:15:
error: use of bitwise '|' with boolean operands
[-Werror,-Wbitwise-instead-of-logical]
      while (((sensors_changed = LowMemoryDetector::has_pending_requests()) |
             ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/java/openjdk13/work/jdk13u-jdk-13.0.10-5-1/src/hotspot/share/runtime/serviceThread.cpp:133:15:
note: cast one or both operands to int to silence this warning
/wrkdirs/usr/ports/java/openjdk13/work/jdk13u-jdk-13.0.10-5-1/src/hotspot/share/runtime/serviceThread.cpp:133:15:
error: use of bitwise '|' with boolean operands
[-Werror,-Wbitwise-instead-of-logical]
      while (((sensors_changed = LowMemoryDetector::has_pending_requests()) |
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/java/openjdk13/work/jdk13u-jdk-13.0.10-5-1/src/hotspot/share/runtime/serviceThread.cpp:133:15:
note: cast one or both operands to int to silence this warning
/wrkdirs/usr/ports/java/openjdk13/work/jdk13u-jdk-13.0.10-5-1/src/hotspot/share/runtime/serviceThread.cpp:133:15:
error: use of bitwise '|' with boolean operands
[-Werror,-Wbitwise-instead-of-logical]
      while (((sensors_changed = LowMemoryDetector::has_pending_requests()) |
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/java/openjdk13/work/jdk13u-jdk-13.0.10-5-1/src/hotspot/share/runtime/serviceThread.cpp:133:15:
note: cast one or both operands to int to silence this warning
/wrkdirs/usr/ports/java/openjdk13/work/jdk13u-jdk-13.0.10-5-1/src/hotspot/share/runtime/serviceThread.cpp:133:15:
error: use of bitwise '|' with boolean operands
[-Werror,-Wbitwise-instead-of-logical]
      while (((sensors_changed = LowMemoryDetector::has_pending_requests()) |
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ... (rest of output omitted)

Although the warning is normally an indication of a potential problem,
in this case a comment just before the affected code explictly mentions
the reason for using bitwise '|' instead of logical '||':

      // Process all available work on each (outer) iteration, rather than
      // only the first recognized bit of work, to avoid frequently true early
      // tests from potentially starving later work.  Hence the use of
      // arithmetic-or to combine results; we don't want short-circuiting.

(See
<https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/serviceThread.cpp#L140>)

Therefore, we should suppress -Wbitwise-instead-of-logical for clang 14
and higher.

PR:		262845
Approved by:	portmgr (build fix blanket)
MFH:		2022Q2

    e406118

04:41 Greg Lewis (glewis) 

java/openjdk13: Update to 13.0.10 GA

    5019cfd

19:22 Greg Lewis (glewis) 

java/openjdk13: Update to 13.0.9

    27a8fe1

12:22 Dimitry Andric (dim) 

java/openjdk*: work around UB in markOopDesc, fix builds with clang 13

During an exp-run for llvm 13 (see bug 258209), it turned out that
java/openjdk11 through openjdk13 fail to build with clang 13:

=== Output from failing command(s) repeated here ===
* For target jdk__packages_attribute.done:

These crashes are all caused by the markOop/markOopDesc classes, which
are used to keep track of objects, and which are 'marked' using the low
few bits. (See
https://github.com/openjdk/jdk13u/blob/master/src/hotspot/share/oops/markOop.hpp
).

After some laborious bisecting, I found out that these crashes start
occuring after the upstream commit https://github.com
/llvm/llvm-project/commit/16d03818412 (Return "[CGCall] Annotate this
argument with alignment").

What happens afterwards, is that clang considers the "this" pointer to
always be aligned to the alignment of the actual object, and then
masking or adding a few low bits is not working as expected.

The reason openjdk14 and higher work fine with clang 13, and don't crash
similarly, is that the OpenJDK people completely redid the
markOop/markOopDesc classes in
https://github.com/openjdk/jdk/commit/ae5615c6142a4dc0d9033462f4880d7b3c127e26
("8229258: Rework markOop and markOopDesc into a simpler mark word value
carrier"). E.g, the markOopDesc class was renamed to markWord, and
*stores* a pointer-like value instead of *being* a pointer-like value.
This is a much safer way of handling things.

However, this upstream commit is *very* large, as are a few of its
follow-ups, which is probably the reason why it has not been backported
to JDKs <= 13. I tried manually backporting it, but got lost in many
nasty patch conflicts and problems.

As a workaround, build openjdk8 through 13 with clang12 from the
devel/llvm12 port, for the time being.

In addition, allow openjdk14 through 17 to be built with clang 13, by
adding -Wno-unused-but-set-parameter to the compilation flags.

PR:		258954
Approved by:	maintainer timeout (2 weeks)
MFH:		2021Q4

    3822416

21:23 Rene Ladan (rene) 

cleanup: drop support for EOL FreeBSD 11.X

Search criteria used:
- 11.4
- OSREL*
- OSVER*
- *_FreeBSD_11

Input from:
- adridg: devel/qca-legacy
- jbeich: _WITH_DPRINTF, _WITH_GETLINE, GNU bfd workarounds
- sunpoet: security/p5-*OpenSSL*

Reviewed by:	doceng, kde, multimedia, perl, python, ruby, rust
Differential Revision: https://reviews.freebsd.org/D32008
Test Plan: make index

    620968a

11:33 Bernhard Froehlich (decke) 

java/openjdk13: Add CPE information

Approved by:	portmgr (blanket)

    43259a2

05:00 Greg Lewis (glewis) 

java/openjdk13: Update to 13.0.8

    b16d9d8

08:09 Mathieu Arnold (mat) 

One more small cleanup, forgotten yesterday.
Reported by:	lwhsu

    cf118cc

14:31 Mathieu Arnold (mat) 

Remove # $FreeBSD$ from Makefiles.

    305f148

11:15 pkubaj 

java/openjdk13: enable dtrace on powerpc64 elfv2

 

18:06 pkubaj 

java/openjdk15: fix build on powerpc64le

Also cosmetic fixes related to powerpc64* for openjdk 12, 13, 14.

 

15:47 pkubaj 

java/openjdk13: add powerpc64le support

 

05:19 glewis 

Update to 13.0.7.1

 

22:16 glewis 

Fix a crash per https://bugs.openjdk.java.net/browse/JDK-8250861

This effectively upgrades us to 13.0.5.1

 

05:27 glewis 

Update to 13.0.5

 

05:09 glewis 

Update to 13.0.4

 

02:13 glewis 

More accurate vendor information

PR:		244634

 

04:41 kevans 

Multiple ports: improve regex compliance

These changes largely fall into just two categories:

1. Need textproc/gsed for GNU extensions
2. Extraneous escapes that can go away

For #1, there's a further subdivision into those that require autoconf magic
and those that can get away with BINARY_ALIAS=sed=${LOCALBASE}/bin/gsed.
-CURRENT will soon gain GNU extensions, but these will take longer to get to
all supported releases; we must switch them to gsed to ensure we're actually
properly building them as intended.

For #2, I've fixed these as I can and we should upstream these fixes.

PORTREVISION is bumped for all of the above, because we will almost
certainly build these differently when the replacements actually start
working.

These were all detected by the below-referenced exp-run [1]. The patch
included forbids many ordinary characters from being escaped, since we'll
later imbue those with special meanings. This has had the nice side effect
of picking up various things that we didn't handle properly, e.g. \t and \r
for tab and carriage return.

PR:		229925 [1]
Approved by:	koobs (mentor)
Approved by:	portmgr (blanket: trivial build fixes)
MFH:		no (invasive risk)
Differential Revision:	https://reviews.freebsd.org/D25185

 

01:41 glewis 

Update to 13.0.3 GA

 

03:26 glewis 

Allow an already installed openjdk13 to be used as a bootstrap

 

09:00 pkubaj 

java/openjdk13: fix compilation for powerpc64 elfv2

Because of issue with macros in precompiled.hpp, --disable-precompiled-headers
is necessary.

Since openjdk compiles for elfv1 by default on big-endian ppc64, use a patch to
compile for elfv2.

PR:		243186
Approved by:	java (maintainer timeout)

 

23:44 glewis 

Update to 13.0.2

Security:	https://openjdk.java.net/groups/vulnerability/advisories/2020-01-14

 

18:03 zeising 

Add USES=xorg USES=gl, ports categories j

Add USES=xorg and USES=gl to ports in categories starting with 'j'
While here, try to sprinkle other USES (mostly gnome and sdl) as needed.

 

17:35 glewis 

Fix build on FreeBSD 12.x/powerpc64 on POWER8+ machines

* Make sure has_mfdscr() returns false on these machines as using it on
  FreeBSD 12.x will cause problems (e.g. SIGILL).

PR:		239368
Sponsored by:	The FreeBSD Foundation

 

20:20 glewis 

Update to 13.0.1 GA

 

15:44 glewis 

Sync with openjdk11

* Separate out platform/compiler concerns
* Disable AoT on all arches except amd64

Sponsored by:	The FreeBSD Foundation

 

00:16 glewis 

Add a port of OpenJDK 13