Clean up after java/openjdk6 removal

[jkim]

Summary

java/openjdk6 and java/openjdk6-jre were deprecated and removed from the ports tree (r512663). This patch removes remaining stuff.

Test Plan

Request exp-run.

[glewis]

LGTM!

Thanks for being so thorough Jung-uk and doing this in a way that will make similar changes much easier in the future.

java/wildfly11/Makefile

6 ↗

(On Diff #64261)

No objection to this, but it seems unnecessary since the other changes should overall be a no-op. Similar comments on the other wildfly ports.

[jkim]

This version cleans up more ports to fix failures reported by exp-run.

[glewis]

Still looks ok to me. I had a couple of comments.

astro/gpsprune/Makefile

6 ↗

(On Diff #64635)

In general, the changes to these ports shouldn't have any functional effect, so I don't know that PORTREVISION needs to be bumped. That said, if it does cause problems bumping PORTREVISION would allow us to detect any problems earlier, so I don't object to it.

astro/gpsprune/files/gpsprune.sh.in

7 ↗

(On Diff #64635)

Note that this may cause a subtle change in behaviour if either the ports tree is not present on a system or if javavmwrapper is otherwise instructed to use it's own internal logic (e.g. if JAVAVM_FALLBACK_ONLY is set).

> env JAVAVM_FALLBACK_ONLY=yes JAVA_VERSION=1.6+ /usr/local/bin/java -version                                                                       openjdk version "12.0.2" 2019-07-16

> env JAVAVM_FALLBACK_ONLY=yes /usr/local/bin/java -version 
openjdk version "13.0.1" 2019-10-15

This will depend on what versions the user has installed. This is actually more of a bug in javavmwrapper which I'll look into (it doesn't understand JDK 13 yet). It also doesn't have a default version (e.g. 8) and uses the "newest" one if no version is supplied. If a version is supplied then it uses the newest version that it understands.

An alternative to all these script changes would be to have bsd.java.mk always add JAVA_VERSION to SUB_LIST, using the version it ends up deciding on if none is set.

[jkim]

astro/gpsprune/files/gpsprune.sh.in

7 ↗

(On Diff #64635)

AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page says:

However, this option, when used with scripts installed by a port,
may result in Java VM selection inconsistent with that intended
by the script author.

[glewis]

astro/gpsprune/files/gpsprune.sh.in

7 ↗

(On Diff #64635)

As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY that you may get different behaviour from what you do when the ports tree is present.

What is a bug is that the presence of "JAVA_VERSION=1.6+" in the two command lines above shouldn't make a difference. Whether it is present or not, the fallback logic should choose the same version. That is what I was pointing out. So by removing that line from the invocation, this change may affect what version is chosen in that situation, even though it shouldn't. The likelihood of this impacting people is quite low though, so I'm not overly concerned. I also have a fix I can commit after this change (I don't want to commit while this is in flight since it will conflict with changes here).

[jkim]

astro/gpsprune/files/gpsprune.sh.in

7 ↗

(On Diff #64635)

Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any difference with or without the ports tree as the PR167799 said.