order of annotations in produced bytecode is not deterministic

[raboof]

This issue is not complete yet, but I wanted to get it out there before I lose track myself :)

Testing with Scala 3.1.1, it seems the same source code may lead to different orderings of annotations and imports in the resulting bytecode. For example for the following sources:

package akka.actor.typed.internal.jfr

import jdk.jfr.Category
import jdk.jfr.Enabled
import jdk.jfr.Event
import jdk.jfr.Label
import jdk.jfr.StackTrace

import akka.annotation.InternalApi

(... snip ...)

/** INTERNAL API */
@InternalApi
@Enabled(true)
@StackTrace(false)
@Category(Array("Akka", "Delivery", "ConsumerController")) @Label("Delivery ConsumerController producer changed")
final class DeliveryConsumerChangedProducer(val producerId: String) extends Event

we saw the following (decompiled-again with procyon -ec) bytecode on one compilation:

package akka.actor.typed.internal.jfr

import akka.annotation.InternalApi
import jdk.jfr.Enabled
import jdk.jfr.Label
import jdk.jfr.StackTrace
import jdk.jfr.Category
import jdk.jfr.Event

@Category({ "Akka", "Delivery", "ConsumerController" })
@StackTrace(false)
@Label("Delivery ConsumerController producer changed")
@Enabled(true)
@InternalApi
public final class DeliveryConsumerChangedProducer extends Event

but on another machine:

package akka.actor.typed.internal.jfr

import akka.annotation.InternalApi
import jdk.jfr.StackTrace
import jdk.jfr.Enabled
import jdk.jfr.Category
import jdk.jfr.Label
import jdk.jfr.Event

@Label("Delivery ConsumerController producer changed")
@Category({ "Akka", "Delivery", "ConsumerController" })
@Enabled(true)
@StackTrace(false)
@InternalApi
public final class DeliveryConsumerChangedProducer extends Event

I seem to remember seeing a similar issue in Scala 2, but can't find a reference right now.

I'll try and dig up further details, and test with a more recent version of scala3, later.

[TheElectronWill]

Imports don't exist at the bytecode level, so that seems to be on procyon.
It's different for annotations, though. I see that java reflection API preserves their order. But does the order really matters?

[raboof]

Imports don't exist at the bytecode level, so that seems to be on procyon.

Gotcha, sorry about that

It's different for annotations, though. I see that java reflection API preserves their order. But does the order really matters?

Perhaps not semantically (though I guess I could come up with some contrived examples), but in general it's attractive when the same source always produces the same 'bit-by-bit' bytecode: such 'reproducible builds' are useful for build systems that rely heavily on caching compiler artifacts and unlock some useful possibilities for security checks - there's some discussion around it in the context of scala 2 at scala/scala-dev#405, for example.

[smarter]

https://github.com/lampepfl/dotty/blob/main/tests/idempotency/IdempotencyCheck.scala checks that for all files in https://github.com/lampepfl/dotty/tree/main/tests/pos compilation is reproducible (it also checks that the order in which we compile files in sub-directories doesn't matter). You can run it manually with scala3-compiler/testOnly *IdempotencyTests, it'd be nice if you could reproduce the issue that way.

[smarter]

See also #7661

[raboof]

it'd be nice if you could reproduce the issue that way

A naive testcase:

import jdk.jfr.Enabled

@Deprecated
@Enabled
object Annotations {
}

doesn't reproduce the problem yet, so that needs some more digging.