Hi Gary,
On 11.11.2025 12:21, Gary Gregory wrote:
> On Tue, Nov 11, 2025 at 3:48 AM Piotr P. Karwasz
> <[email protected]> wrote:
>> - The change disabling JDK 26-ea runs was submitted by me as a PR and
>> approved by Sebb [1], representing a two-party review and agreement.
>
> Then I am -1 that change, as it is an obvious mistake or
> misunderstanding of what GitHub _experimental_ builds are.
You are, of course, free to veto the change and we can discuss its
merits. However, silently reverting it without any explanation is not
acceptable practice.
> As I've outlined in the (recent) past many times, _all_ EA builds
> are marked _experimental_ in all of Commons:
> - Lang should not be different from all other components in this regard.
For clarity, this discussion concerns Compress, not Lang.
> - The comment is wrong since the build has been passing using PMD on
> Java 26, this alone should invalidate disabling the experimental
> build.
That is not the case. The most recent build on `master` [1] clearly
shows a PMD failure:
[INFO] --- pmd:3.28.0:pmd (pmd) @ commons-compress ---
[INFO] PMD version: 7.17.0
Error: Parsing failed in ParseLock#doParse() of ClassStub:java/lang/String
java.lang.IllegalArgumentException: Unsupported class file major version 70
at org.objectweb.asm.ClassReader.<init> (ClassReader.java:200)
at org.objectweb.asm.ClassReader.<init> (ClassReader.java:180)
at org.objectweb.asm.ClassReader.<init> (ClassReader.java:166)
at org.objectweb.asm.ClassReader.<init> (ClassReader.java:288)
at
net.sourceforge.pmd.lang.java.symbols.internal.asm.ClassStub$1.doParse
(ClassStub.java:98)
As we all know, this indicates that PMD 7.17.0 depends on an ASM version
that does not yet support Java 26. Updating ASM or PMD will resolve the
issue.
However, neither of those updates was made before re-enabling the
workflow. As a result, the build now reports false positives like those
seen in [2]. Apparently, even GitBox or GitHub don’t fully grasp what
“experimental” means here.
> - This allows us to detect problems _early_ in our own code and in the
> FOSS ecosystem at large. We can then feedback into other projects
> (which I often do).
> - They don't break the other builds in the matrix
Honestly, Gary, what kind of feedback can we provide if the build
appears red regardless of any unit test results? Without checking the
details, one cannot tell whether the experiment itself works or if it’s
simply failing due to external tooling limitations.
Piotr
[1]
https://github.com/apache/commons-compress/actions/runs/19197689377/job/54881035193
[2] https://lists.apache.org/thread/8zxz6q9sj252o9o092hjg0gprf9z8gkn
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
