Mysterious comparator errors on org.eclipse.jdt.core.compiler.batch

[iloveeclipse]

Follow up on #1388

After "fixing" the original issue we've observed in https://download.eclipse.org/eclipse/downloads/drops4/I20230922-1800/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt, the next build was OK but one build after was reported as unstable for exact same reason:

https://download.eclipse.org/eclipse/downloads/drops4/I20230923-1800/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt

1.  eclipse.jdt.core/org.eclipse.jdt.core.compiler.batch/pom.xml
   no-classifier: different
      org/eclipse/jdt/internal/compiler/ast/TypeReference.class: different
      org/eclipse/jdt/internal/compiler/parser/Parser.class: different
    The main artifact has been replaced with the baseline version.
    The following attached artifacts have been replaced with the baseline version: [sources]

However there is no artifactcomparisons.zip generated / linked to https://download.eclipse.org/eclipse/downloads/drops4/I20230923-1800/buildlogs.php that would show bytecode diff.

I assume this is a tycho issue, may be related to the "special" way we build org.eclipse.jdt.core.compiler.batch bundle for #1203.

Note: very last SDK build was OK, but only because we had real changes on batch compiler.

So what we need is:

1. Understand where is the problem of "changed" bytecode is coming from (recent tycho change?).
2. Make sure artifactcomparisons.zip is generated for org.eclipse.jdt.core.compiler.batch if buildtimeComparatorUnanticipated.log.txt
3. Understand where is the problem of "changed" bytecode is coming from (Java 21 branch merged recently to jdt?).

[iloveeclipse]

@laeubi : could you please check this?

[laeubi]

@iloveeclipse as far as I can see a released Tycho version is now used so you should not see any changes in Tycho

Only thing I could think of would be that a changed compiler is used in the I-Build but the published repository is published by another step using "old" compiler but the full I-Build is kind of a mystery, is this visible also in the local build when one runs https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/ ?

[iloveeclipse]

is this visible also in the local build

As far as I know the artifactcomparisons.zip & Co are only generated for eclipse.org I-builds / website publishing.

[laeubi]

If you specify -Dcompare-version-with-baselines.skip=false it should be enabled and fail the build, I think the I build works with this disabled an scans the log for such messages later on but @mickaelistria can maybe better tell here.

[mickaelistria]

To fail the build in case of errors -Dcompare-version-with-baselines.skip=false should do the trick.
But I-Builds use another strategy (IIRC they do run the apitools application after the build) as they generate some report flles that plain Tycho check doesn't generate.

[iloveeclipse]

As expected, we have comparator errors in https://download.eclipse.org/eclipse/downloads/drops4/I20230925-1800/

Same errors: https://download.eclipse.org/eclipse/downloads/drops4/I20230925-1800/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt

No zip file with diffs: https://download.eclipse.org/eclipse/downloads/drops4/I20230925-1800/buildlogs.php

[laeubi]

So how do I access the logfiles of the maven build?

I tried https://download.eclipse.org/eclipse/downloads/drops4/I20230925-1800/ > "View the logs for the current build." but this seems to only cover test result logs.

[iloveeclipse]

Release engineering build logs

https://download.eclipse.org/eclipse/downloads/drops4/I20230925-1800/buildlogs.php
https://download.eclipse.org/eclipse/downloads/drops4/I20230925-1800/buildlogs/mb060_run-maven-build_output.txt

[laeubi]

@iloveeclipse thanks, looking at the logs the problem is quite clear because the message is emitted at the phase where the compiler is build for the I-Build itself, I think at that stage we should simply disable the baseline replace check all together.

[iloveeclipse]

Why did it work before?

[laeubi]

It seems now JDT produces a little bit different byte-code, so what happens is this:

1. compiler is compiled with "old" bytecode
2. this compiler is then used to produce a compiler jar with "new" bytecode
3. then this is deployed to the ibuild repository
4. on the next cycle the compiler is compiled with "old" bytecode and compared to the artifact with "new" bytecode
5. --> comparator error

[iloveeclipse]

OK, is the "old" compiler == 4.29 version? The "new" one is created after merging Java 21 branch to master, and we know we had generation changes, see #1378 .

So @laeubi : could you push fixed maven call?

[laeubi]

How to reproduce:

1. fetch the aggregator repositories
2. run mvn clean install -pl :eclipse-sdk-prereqs,:org.eclipse.jdt.core.compiler.batch -DlocalEcjVersion=99.99
3. You see the follwoing warning in the build log:

[WARNING] MavenProject: org.eclipse.jdt:org.eclipse.jdt.core.compiler.batch:3.36.0-SNAPSHOT @ eclipse-aggregator/eclipse.platform.releng.aggregator/eclipse.jdt.core/org.eclipse.jdt.core.compiler.batch/pom.xml: baseline and build artifacts have same version but different contents
   no-classifier: different
      org/eclipse/jdt/internal/compiler/ast/ExpressionContext.class: different
      org/eclipse/jdt/internal/compiler/ast/TypeReference.class: different
      org/eclipse/jdt/internal/compiler/parser/Parser.class: different

[laeubi]

@iloveeclipse this is a preliminary change required to fix the problem:

• Make the compiler baseline configuration configurable by properties eclipse-jdt/eclipse.jdt.core#1435

[akurtakov]

one way to try workarounding the issue is:

• deploy latest batch compiler https://ci.eclipse.org/jdt/job/copyAndDeployJDTCompiler/
• switch to it in https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse-platform-parent/pom.xml#L89

Thinking more about it - it has to be done regardless of other fixes so all other builds use the new compiler not only the Ibuild.

[laeubi]

Here is the fix for ibuild when JDT changes are merged:

• Disable baseline validation/replace when building the compiler-compiler #1401

[iloveeclipse]

@laeubi : thanks, I've merged both commits. Are we ready for new IBuild, or should we wait for regular one?

[iloveeclipse]

Are we ready for new IBuild,

There are also two Javadoc errors shown in releng tests that we could fix first.

[iloveeclipse]

Thinking more about it - it has to be done regardless of other fixes so all other builds use the new compiler not only the Ibuild.

This should happen anyway after M1. Let us see if the two merged PRs fixed the issue.

[iloveeclipse]

Let us see if the two merged PRs fixed the issue.

Yep: https://download.eclipse.org/eclipse/downloads/drops4/I20230926-0600/